Batch create/update/upsert/delete ({collection.name})

Batch and transactional create/update/upsert/delete of multiple records in a single request.

The batch Web API need to be explicitly enabled and configured from the Dashboard settings.

Because this endpoint process the requests in a single transaction it could degrade the performance of your application if not used with proper care and configuration (e.g. too large allowed execution timeout, large body size limit, etc.).

API details
POST
/api/batch
Body Parameters

Body parameters could be sent as application/json or multipart/form-data.
File upload is supported only via multipart/form-data (see below for more details).

Param Description
Required requests
{`Array`} - List of the requests to process.

The supported batch request actions are:

  • record create - POST /api/collections/{`{collection}`}/records
  • record update - PATCH /api/collections/{`{collection}`}/records/{`{id}`}
  • record upsert - PUT /api/collections/{`{collection}`}/records
    (the body must have id field)
  • record delete - DELETE /api/collections/{`{collection}`}/records/{`{id}`}

Each batch Request element have the following properties:

  • url path (could include query parameters)
  • method (GET, POST, PUT, PATCH, DELETE)
  • headers
    (custom per-request Authorization header is not supported at the moment, aka. all batch requests have the same auth state)
  • body

NB! When the batch request is send as multipart/form-data, the regular batch action fields are expected to be submitted as serailized json under the @jsonPayload field and file keys need to follow the pattern requests.N.fileField or requests[N].fileField (this is usually handled transparently by the SDKs when their specific object notation is used) .
If you don't use the SDKs or prefer manually to construct the FormData body, then it could look something like:

Responses
{#each responses as response (response.code)} {/each}
{#each responses as response (response.code)}
{/each}