bodyobject
Specify the request body for the sub-request.
> **Note**
> - **Using References in Composite API Requests**: You can reference the output of one sub-request in another within the same API call.
> - **Reference Structure**: `@{sub_request_id:JSONPath}`
> Where,
> - `sub_request_id` is the ID of the sub-request whose response you want to reference.
> - `JSONPath` is the path to the specific field in that response.
> For example, if you create a Lead in one sub-request (sub_request_id : 1) and need to update it in another, you can use `@{1:$.data[0].details.id}` to dynamically fetch the Lead ID from sub-request 1 and use it in sub-request 2 to modify the same record.
> - The `rollback_on_fail` and `parallel_execution` keys cannot both be set to `true`. If both are enabled, the API returns the `AMBIGUITY_DURING_PROCESSING` error.
> - All Delete APIs (except Notification APIs) support only record IDs in the URL. Bulk delete operations are not supported.
> - When `rollback_on_fail` is `false`:
> - Workflows, approvals, and other automation actions are triggered as intended.
> - The Composite API consumes one API credit.
> - When `rollback_on_fail` is `true`:
> - **Workflows**
> - Automation actions execute only after all sub-requests complete successfully and no rollback occurs. If one or more sub-requests fail and a rollback happens, the automation actions are not triggered.
> - For example, consider the case where a workflow is triggered every time a lead is created with the company name starting with 'S'. In sub-request 1, a lead is created, whose Company name starts with 'S', and sub-request 2 edits the newly created record's company name so that it does not start with 'S'. Only after executing both the sub-requests the workflow will be executed. But in this case, the workflow will not be triggered because the newly created Lead's company name is already updated in sub-request 2, and the criterion for the workflow is not met. Consider another case, where in sub-request 1, a lead is created, whose Company name is 'Silicon Solutions', and sub-request 2 edits this newly created record's website. If none of the other sub-requests change the company name of this newly created record, after executing all the sub-requests successfully, the workflow will be triggered.
> - When a rollback occurs, the Composite API consumes one API credit.
> - When all sub-requests succeed, the Composite API consumes two API credits.
> - Each Composite API request consumes **five concurrency credits**, regardless of the number of sub-requests.
> - Each composite API reduces the sub-concurrency by one, while the sub-requests consume their respective sub-concurrencies.
### Allowed APIs
The following table gives the list of APIs allowed in a composite request. For these APIs, there are restrictions on the number of records that you can create, update, or delete in a composite request.
| API | No. of records allowed |
| --- | --- |
| Get Org, Get Metadata, Convert a Lead, Get Layout Rules, Get Validation Rules, Get Custom Links, Get/Add/Update Roles, Get Profiles, Get Records' Count, Get/Update Blueprint, Get Variables/Variable Groups, Get Tags, Add/Remove Tags for a record, Get List of Attachments, Delete Photo, Get Currencies, Get Shared Record Details, Get Assignment Rules, Get/Add/Update Pipeline, Get Wizards, Get List of From Addresses, Delete Notifications | No Restriction |
| Add/Update/Delete Users, Update/Delink Related Records, Add/Delete Variables, Create/Update/Delete Notes, Create/Update/Merge Tags, Add/Update Currency, Add/Update/PATCH Notifications, Create/Update/Upsert/Delete Records | 1 |
| Get Territories, Get Notes, Get Email/Inventory Templates, Get Notifications, Get/Search Records, Get Related Records, Get records through a COQL query, Get Deleted Records, Get Users | 25 |
