Everything in this section behaves the same way no matter which module you are sending to. Read it once, then work from your module guide for the records themselves.
Authentication
Logging in, the 15-minute access token expiry, and refreshing a token part-way through a long load without re-sending the password.
Conventions
The ExternalId upsert rule, the required CompanyId, the
X-Source-System header, the fields we fill in for you, and the response envelope.
Batch endpoint
Send many records in one call. Operations can span modules, declare dependencies on each other, and report success or failure individually.
Members
Creating and checking internal Ketendo users - your own staff, as opposed to the people and organisations you trade with.
Reconciliation
Look a record up by the ExternalId you sent, to verify a sync or work out why something does not match what you expected.
The short version
- Authenticate, and refresh the token if your load runs longer than about 15 minutes.
- Send
CompanyIdandX-Source-Systemon every call. - Give every record your own
ExternalId. Sending the same one again updates rather than duplicates, which makes every call safe to retry. - Upload dependencies before the things that point at them. Each module guide lists its own order.
- Use the batch endpoint once you are past testing.
Two kinds of endpoint
Most of what you will use sits under /v1/integration/ - upsert endpoints keyed on your
own identifier, which is where the conventions above apply. A few reference lists live on ordinary
/v1/ endpoints instead, because they are the same lists the Ketendo portal reads. Those
take a plain Authorization header and no X-Source-System; each one says so
where it is documented.