The API exposes the product’s operations as named actions. It is the supported way to integrate; reading or writing the database directly is not.
Authentication
API access is granted through API credentials with an associated role, so an integration holds only the actions it needs. Treat credentials as secrets: rotate them when someone leaves, and never place them in a URL, where they land in server logs and browser history.
Credentials that work from anywhere are credentials that work from anywhere they leak to.
Actions
Each action is addressed by name and takes its own parameters. There are 137 of them, covering clients, orders, services, invoices, transactions, tickets, products, and administrative operations. An action either succeeds and returns its data, or returns a result describing why it did not.
Action names and the US-English rename
Action names are a public contract, so the 1.5.0 spelling change did not break them. getcancelledpackages still works and forwards to getcanceledpackages; the old name is deprecated rather than removed. New integrations should use the US spelling.
An integration that compares a returned status against the literal Cancelled must be updated to Canceled. This is the one API-visible change in that release.
Reading a response
- Check the result field before reading anything else. A response with data in it can still be a failure.
- Do not infer success from an HTTP status alone.
- Expect new fields to appear over time. Read the fields you need rather than validating the whole shape.
Load
The API runs against the same database as the customer-facing site. A polling integration that asks every few seconds for something that changes daily is a self-inflicted performance problem. Poll at the rate the data actually changes, or react to a hook instead.
API log
API requests are logged with their action and outcome. When an integration misbehaves, read the log before adding instrumentation to the integration — the answer is usually there.