PUT /entity/{id}

Update an entity.

If the Entity is a FileEntity and the dataFileHandleId fields is set to a new value, then a new version will automatically be created for this update if the MD5 of the new file handle does not match the MD5 of the existing file handle or if the file handles do not have an MD5 set. You can also force the creation of a new version using the newVersion parameter (see below).

Synapse employs an Optimistic Concurrency Control (OCC) scheme to handle concurrent updates. Each time an Entity is updated a new etag will be issued to the Entity. When an update is request, Synapse will compare the etag of the passed Entity with the current etag of the Entity. If the etags do not match, then the update will be rejected with a PRECONDITION_FAILED (412) response. When this occurs the caller should get the latest copy of the Entity (see: GET /entity/{id}) and re-apply any changes to the object, then re-attempt the Entity update. This ensure the caller has any changes applied by other users before applying their own changes.

Note: To update an Entity the caller must be granted the ACCESS_TYPE.UPDATE on the Entity.

Service Limits

resource limit
The maximum number of children for a single parent entity 10 K

Resource URL


Resource URL Variables
{id} The ID of the entity to update. This ID must match the ID of the passed Entity in the request body.


To track the Provenance of an Entity update, include the ID of the Activity that was created to track the change. For more information see: POST /activity. You must be the creator of the Activity used here.


To force the creation of a new version for a versionable entity such as a FileEntity, include this optional parameter with a value set to true (i.e. newVersion=true). This parameter is ignored for entities of type Table (See POST /entity/{id}/table/snapshot instead)
Resource Information
Authentication Required
Required OAuth Scopes view , modify
Request Object Entity
Response Object Entity