Idempotency
Management writes accept an Idempotency-Key header so retries are safe. Send a
fresh key for each distinct action, and reuse the same key only when retrying that
exact action.
Idempotency-Key: 6f9619ff-8b86-d011-b42d-00c04fc964ff
Client rule
Send Idempotency-Key on every non-GET Management request. The current
Management REST surface applies replay protection to mutating methods:
| Operation | operationId | Required scope |
|---|---|---|
| POST /v1/classes | managementCreateClass | classes:write |
| PATCH /v1/classes/{classId} | managementUpdateClass | classes:write |
| DELETE /v1/classes/{classId} | managementCancelClass | classes:write |
| POST /v1/members/invites | managementInviteMember | members:write |
| PATCH /v1/schedule/{occurrenceId} | managementRescheduleOccurrence | schedule:write |
| PATCH /v1/content/{contentId} | managementUpdateContent | content:write |
| DELETE /v1/content/{contentId} | managementDeleteContent | content:write |
| POST /v1/plans | managementCreatePlan | plans:write |
| PATCH /v1/plans/{planId} | managementUpdatePlan | plans:write |
| DELETE /v1/plans/{planId} | managementArchivePlan | plans:write |
| POST /v1/instructors | managementCreateInstructor | instructors:write |
| PATCH /v1/instructors/{instructorId} | managementUpdateInstructor | instructors:write |
| POST /v1/locations | managementCreateLocation | locations:write |
| PATCH /v1/locations/{locationId} | managementUpdateLocation | locations:write |
| DELETE /v1/locations/{locationId} | managementDeleteLocation | locations:write |
| POST /v1/locations/{locationId}/rooms | managementCreateRoom | locations:write |
| PATCH /v1/locations/{locationId}/rooms/{roomId} | managementUpdateRoom | locations:write |
| DELETE /v1/locations/{locationId}/rooms/{roomId} | managementDeleteRoom | locations:write |
| PATCH /v1/members/{membershipId} | managementUpdateMember | members:write |
| POST /v1/members/{membershipId}/cancel | managementCancelMembership | members:write |
| POST /v1/coupons | managementCreateCoupon | coupons:write |
| DELETE /v1/coupons/{couponId} | managementArchiveCoupon | coupons:write |
| POST /v1/programs | managementCreateProgram | programs:write |
| PATCH /v1/programs/{programId} | managementUpdateProgram | programs:write |
Retry behavior
The first request with a key performs the action and stores the response. A retry with the same method, path, body, and key returns the stored response instead of performing the action again.
A retry that reuses the same key for a different request returns 409 Conflict
with a Problem body. Treat that as a client bug: generate a new key for the new
action.
Practical guidance
- Generate UUIDs or another high-entropy unique value.
- Keep the same key across automatic network retries.
- Keep the same key across a user-visible retry button for the same action.
- Do not reuse keys across different actions, even if the payloads look similar.
- Persist keys long enough to survive your own retry window.