# Apply for several shifts at once

Puts the signed-in person on every shift in the body. This is what the cart submits
when someone has finished choosing shifts, and it is the endpoint that actually
creates the applications - the check that runs as each shift goes into the cart
does not.
**The shifts are not named in the URL; they are the `shifts` array in the body**,
and each entry has to carry both `event_shift_id` and `leader_applied` even when
leading is not being asked for. An entry missing either comes back as a 422 saying
"Incorrect data structure" against `shifts`.
**All or nothing.** Every shift is checked before any application is made, and one
shift that cannot be taken refuses the whole request with a 422 whose `errors`
names each shift and says why. The applications, any payment and any linked-series
joins are made together, and a failure anywhere undoes all of it - including
voiding a payment that had already been authorised. A 200 with an empty body means
every application was made.
Where the event sets a minimum number of shifts per person, or a minimum per shift
type, a request that would leave the person short is refused here rather than
shift by shift.
Sending the same set of shifts twice within ten seconds returns a 429; the second
request is treated as a double submission rather than a second application.

Endpoint: POST /api/v2/event/shift/apply-all
Version: 2.0.0
Security: default

## Header parameters:

  - `Rosterfy-Platform` (string)

## Request fields (application/json):

  - `shifts` (array, required)
    The shifts to apply for, one object per shift. The rule says only "array", so the shape of an entry is stated here rather than in the schema. Every entry takes: `event_shift_id` (integer, **required**) the shift being applied for; `leader_applied` (0 or 1, **required** on every entry even when it is 0) whether the application is to lead the shift; `application_form` (object, optional) the answers to that shift's application form, keyed by the field codes your account configured; `linked` (boolean, optional) also join the linked series the shift belongs to, so the person is put on its other shifts; and `in_cart` (boolean, optional) which marks an entry as already in the cart and is ignored here - every entry is applied for whether or not it is set. An entry missing `event_shift_id` or `leader_applied` is refused with "Incorrect data structure" against `shifts`, and no application is made for any of them.

  - `paymentData` (object)
    Payment details for shifts that cost money. Read only when the account has a payment provider configured, and ignored otherwise. The keys are the provider's own; a failed payment removes the applications it was for.

## Response 422 fields (application/json):

  - `message` (string)

  - `errors` (array)

  - `errors.event_shift_id` (integer)

  - `errors.message` (string)

## Response 429 fields (application/json):

  - `message` (string)