# Add many users to a role offer

Adds a set of people to the role offer in the URL at once.
**This write is queued.** The response does not contain the applications and
does not mean they exist yet - it means the request was accepted and the work is
running in the background. The payload is a single `queue` field holding an
identifier for that work. There is no endpoint that resolves the identifier, so
confirm the outcome by listing the role offer's applications.
Choose the people either way round:
- Send `applyTo` as `selected` with `selected` holding the user IDs to add.
- Send any other `applyTo` value to add every user the caller can see, narrowed
by an optional `filter` in the same form the user listing accepts.

People who already hold an application on this role offer are skipped, so the
same request can be repeated safely.
The same demand, allowance and transition limits the single create is subject to
apply to each person here, but because the work is queued they cannot be reported
back: a person the limits refuse is skipped and the request still returns a queue
token. **A request whose fields are all valid therefore always succeeds, whether
or not anybody is added.** Only malformed input is refused, with a 422 before
anything is queued.

Endpoint: PUT /api/v2/headcount/roleoffer/{roleoffer_id}/user
Version: 2.0.0
Security: default

## Path parameters:

  - `roleoffer_id` (integer, required)
    The ID of the role offer.

## Header parameters:

  - `Rosterfy-Platform` (string)

## Request fields (application/json):

  - `applyTo` (string, required)
    Send `selected` to add only the users named in `selected`. Any other value adds every user the caller can see, narrowed by `filter` if one is sent. The value is not checked against a list, so a typo is accepted and treated as "everyone".

  - `selected` (array)
    The IDs of the users to add. Required in practice when `applyTo` is `selected` and ignored otherwise, but nothing validates that: omitting it still returns a queue token, and the background work then adds nobody.

  - `status_id` (integer)
    The status to start each new application on. Defaults to the account's own default applied status. Not validated here, so an id that does not exist is accepted and the background work fails rather than the request.

## Response 200 fields (application/json):

  - `queue` (string)