The documentation for the REST API lists the entities that are supported for CRUD actions. For each entity examples of the JSON payload for each HTTP method are provided. And what is more, the documentation provides a Postman Collection that shows how interaction with the Notes table can be performed.

Consider the update of a Note record.

The request above has been directed at

HTTP://[servername]/sdata/[installname]j/sagecrm2/-/Notes('1')

The primary key of the Note record to be updated is contained in the last part of the path, 'the specifier'.

The JSON package would look something like

{
"$key": 1,
"Note_Note": "Update: This is an updated demo note linked to the Gatecom company.",
"Note_ForeignTableId": 5,
"Note_ForeignId": 28
}

That is the data that would then be submitted within the HTTP Request using the 'Patch' verb. If the update is successful then Sage CRM will respond with a '200' message.

Assumption

An assumption has been made about that return. The assumption is that if we have submitted the data then we can assume that should be the data contained in the result. By default whenever the REST API inserts or updates a record, the response set is read from memory. Importantly, this provides better performance than by reading the data back from the database.

In most circumstances, it is reasonable to assume that the data in memory will be the same that is stored in the database. This may not be true where data transformation takes place because of a Table Level Script. To be certain you can add the flag "returnPartial=false;" to the URL.

HTTP://[servername]/sdata/[installname]j/sagecrm2/-/Notes('1')?returnPartial=false