All timestamps, such as expiration dates, are in ISO8601 format in the UTC (Z) timezone.

Most non-200 response codes (except 404) will include a JSON error document. Error descriptions look like:

{
    "error": {
        "status":  423,                          # HTTP status code
        "code":    "DatabaseLocked",             # error code
        "message": "The database is already locked by someone else",
    }
}

Every request has an associated unique request id (a UUID). This is returned in the HTTP response headers as:

X-Request-Id: a8098c1a-f86e-11da-bd1a-00112444be1e

and in the body of all JSON response documents as:

{
    "request_id": "a8098c1a-f86e-11da-bd1a-00112444be1e",
    ...
}

These are also associated with log messages. This makes it easy to tie a request in a remote system to a request on the server.

The master node is the definitive source of information and will never be updated with changes made to the database at the slave node. Any changes made to the slave node between synchronisation calls will be undone during synchronisation.

Changes made at either the parent or the child node will be applied to the other node. This include all operations: insert, updated and delete. Should there be any sort of conflict, for example the record got deleted on one node and updated on the other, conflict resolution will always favour the parent node.