The same API we build on.
RouteIQ's dashboard and driver app run on the REST API you get: 180+ endpoints, documented in an OpenAPI 3.0 spec. If it's in the product, you can automate it.
Your first request
Every site gets its own subdomain, and every request is scoped to it. Sign in, take the access token, and send it as one header.
# Base URL: https://<your-subdomain>.routeiq.app/api # One header authenticates every request curl -X POST https://acme.routeiq.app/api/job \ -H "x-access-token: $ROUTEIQ_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customer_first_name": "Dana", "customer_phone": "2125550100", "service_type_id": 12, "stops": [ ... ] }' # List jobs, newest first curl "https://acme.routeiq.app/api/job?page=1&per_page=20&sort_by=created_at&sort_order=desc" \ -H "x-access-token: $ROUTEIQ_ACCESS_TOKEN"
One header, every request
The access token identifies the user and the application in one credential. The dashboard, the driver app, and your integrations all authenticate the same way. For server-to-server jobs with no signed-in user, use an API key instead.
| Header | Use it for | Where it comes from |
|---|---|---|
x-access-token: <token> |
Everything a signed-in user does. The application is resolved from the token, server-side. | Obtained by signing in (see the authentication endpoints in the API reference); expires and must be refreshed. |
x-api-key: <key> |
Server-to-server requests with no signed-in user. The key acts through its own service account. | Register an application in your site settings and scope keys to it. |
Boring, in the good way
The API behaves the same everywhere, so you learn it once.
| Concern | How it works |
|---|---|
| Multi-tenancy | Every request is scoped to a site by subdomain. Data is fully isolated between sites; credentials from one site cannot touch another. |
| Pagination | page and per_page (default 20, max 100). Responses include
a meta object with total, page, and
per_page. |
| Sorting | sort_by=<field> with sort_order=asc or
desc, e.g. sort_by=created_at&sort_order=desc. |
| Errors | Consistent JSON: {"error": "message", "code": "ERROR_CODE"} with
standard HTTP status codes (400, 401, 403, 404, 409, 422, 500). |
| Rate limiting | Per API key or token. Exceeding it returns 429 with a
Retry-After header telling you when to come back. |
| Partial updates | PATCH uses a three-state model: send a value to set it, omit the field to leave it
unchanged, send null to clear it. |
Not married to one map vendor
Routing, geocoding, and traffic data flow through a provider abstraction with a stable interface. We can switch vendors per site for accuracy, coverage, or cost, and a provider outage doesn't take routing down with it. Included mapping and routing currently covers Europe and the Americas; other regions require a supported third-party mapping integration.
Webhooks that don't lose things
Subscribe your endpoints to the events you care about: job state changes, payments, driver status. Delivery is queue-based and retried on failure, so a blip on your end doesn't mean a missed update.
Custom fields
Attach your own structured data to jobs, workers, and stops through the API. No schema change requests, no waiting on us.
Configurable workflows
Job, stop, and route states are defined per site over the API. Five fixed lifecycle phases underneath keep your automations stable whatever the states are named.
Integrations
Stripe, Twilio, Slack, Mailgun, Firebase push, and LiveKit are first-class integrations. Credentials are encrypted field-by-field at rest.
Audit log
Every change is recorded in an append-only log with the before and after state. Query it through the API like anything else.
Read the full reference
All 180+ endpoints with schemas, parameters, and example payloads, rendered straight from the OpenAPI spec.