Update Multiple Records with Fewer Round-Trips

Use a PATCH request with sObject Collections to update multiple records, returning a list of SaveResult objects. You can choose whether to roll back the entire request when an error occurs.

Where possible, we changed noninclusive terms to align with our company value of Equality. Because changing terms in our code can break current implementations, we maintained this object’s name.

Important

Request Syntax

PATCH /vXX.X/composite/sobjects

Parameters

Parameter	Description
allOrNone	Optional. Indicates whether to roll back the entire request when the update of any object fails (`true`) or to continue with the independent update of other objects in the request. The default is `false`.
records	Required. A list of sObjects. In a POST request using sObject Collections, set the `type` attribute for each object. You can set either the `id` field or, if available, the FullName field for any object.

Usage Guidelines

The maximum number of objects in the list can be different for each Tooling API object.
The list can contain objects of different types, including custom objects.
Each object must contain an attributes map. The map must contain a value for type.
If the object has a Metadata field, you can specify either an id field with a valid ID value or the FullName field. If the object doesn’t have a Metadata field, the id field with a valid ID value is required.
Objects are updated in the order they’re listed. The SaveResult objects are returned in the order in which the update requests were specified.
If the request body includes objects of more than one type, they’re processed as chunks. For example, if the incoming objects are {objectA1, objectA2, objectB1, objectA3}, the request is processed in three chunks: {{objectA1, objectA2}, {objectB1}, {objectA3}}. A single request can process up to 10 chunks.
Although SObject Collections is also supported in SOAP API, you can’t use SOAP API objects in a Tooling API SObject Collections call.

Checking for Errors

If the request isn’t well formed, the API returns a 400 Bad Request HTTP Status. Fix the syntax of the request and try again.
If the request is well formed, the API returns a 200 OK HTTP Status. If an item was processed successfully, the success flag shows for that item. Error information is returned in the errors array.

Response Body Examples

This example shows a response when all the items were processed successfully.

1HTTP/1.1 200 OK
2
3[
4   {
5      "id" : "001RM000003oCprYAE",
6      "success" : true,
7      "errors" : [ ]
8   },
9   {
10      "id" : "003RM0000068og4YAA",
11      "success" : true,
12      "errors" : [ ]
13   }
14]

This example shows a response when some items caused errors and allOrNone is false.

1HTTP/1.1 200 OK
2[
3  {
4    "id": "001RM000003oCprYAE",
5    "success": true,
6    "errors": [
7      
8    ]
9  },
10  {
11    "success": false,
12    "errors": [
13      {
14        "statusCode": "MALFORMED_ID",
15        "message": "Duplicate Fullname",
16        "fields": [
17          "Id"
18        ]
19      }
20    ]
21  }
22]

This example shows a response when some items caused errors and allOrNone is true.

1HTTP/1.1 200 OK
2[
3  {
4    "id" : "001RM000003oCprYAE",
5    "success" : false,
6    "errors" : [
7      {
8      "statusCode" : "ALL_OR_NONE_OPERATION_ROLLED_BACK",
9      "message" : "Record rolled back because not all records were valid and the request was using AllOrNone header",
10      "fields" : [ ]
11      }
12    ]
13  },
14  {
15    "success" : false,
16    "errors" : [
17      {
18        "statusCode" : "MALFORMED_ID",
19        "message" : "Duplicate Fullname",
20        "fields" : [
21          "Id"
22        ]
23      }
24    ]
25  }
26]

Tooling API