Quatlas Integration API
The Integration API connects your own systems (an ERP, a BPM tool such as eBA, a script) to Quatlas. Your system opens shipment requests, follows them through the marketplace and the operation, reads the deals your company is a party to, and hears about what happens through signed webhooks.
What you can do today
Section titled “What you can do today”- Create shipment requests as a draft or published, from a record in your system. Your own id for the record goes in
externalReference, and the same reference never opens a second request. - Update and cancel the requests created through the API, where the app’s rules allow: a published request’s listing, and a cancel before the award. See Updating and cancelling.
- Keep your own fields on a request (a cost centre, an order or a process number) as metadata, visible only to your company.
- Read a request by its id or by your
externalReference: its status, how many offers are open (a count only), the awarded carrier once the app names it, the deal and the operation status. - Read deals your company is a party to, as your company sees them in the app: the agreed price, the Incoterm, the counterparty, the stage, the documents (and a short-lived download link for a clean file), the milestones and estimated delivery, and the additional costs with the statement totals.
- Upload documents into a deal (an invoice, a packing list, a transport document) under the app’s upload rules, malware scan and the categories it offers your side. See Uploading documents.
- Hear about events through signed webhooks: a request published, updated or cancelled, an offer received, a deal live, a milestone, a delivery, a document, a cost, an invoice.
- Test in a sandbox with a test key: the same calls, never touching real data, and an endpoint that moves a test request through its life.
Version 1 does not place offers, accept them, run the closing room or the operation, withdraw a deal or cancel an operation: those stay in the app. Requests have no list endpoint: read them one at a time, by id or by externalReference, or listen to webhooks.
Live and sandbox
Section titled “Live and sandbox”Every key is either live or test, and the mode is part of the key:
| Key | Starts with | Works on | Answers say |
|---|---|---|---|
| Live | qk_ |
Your company’s real data | "livemode": true |
| Test | qk_test_ |
A sandbox kept for your company | "livemode": false |
Both use the same base URL, routes, scopes, IP allowlist and rate limit. A test request never reaches the marketplace, never notifies anyone and is deleted after 30 days. See Sandbox.
At a glance
Section titled “At a glance”| Base URL | https://app.quatlasglobal.com/api/integrations/v1 |
| Authentication | Authorization: Bearer qk_..., or a 15-minute OAuth 2.0 access token |
| Format | JSON (UTF-8). Only the token request is form-encoded. Times are UTC. |
| Errors | application/problem+json with a stable code |
| Rate limit | 60 calls a minute per key on Exchange, 300 on Enterprise |
| Webhooks | Signed POSTs (HMAC-SHA256) with a thin body |
| OpenAPI | https://app.quatlasglobal.com/openapi/integrations-v1.json |
Who can use what
Section titled “Who can use what”- Creating requests is for shipper companies. A key of a company that is not a shipper gets
403(Company.WrongSegment) on create. - Deal reads and webhooks work for both sides of a deal. A carrier’s key reads the deals its company won, as the carrier sees them.
- Every read answers only for records your company owns or is a party to. Anything else answers
404, exactly as if it did not exist.
Next steps
Section titled “Next steps”Support
Section titled “Support”Write to [email protected]. Include the time of the call, its route and your key’s prefix (qk_ and the 12 characters after it). Never send the key itself.