Loading...
Loading...
If you already run a PMS, a channel manager or your own tooling, you should not be retyping properties and work orders into a second system. The Dispatch API is REST over JSON at https://cmms.turnwrk.com/api/v1 — bearer token in, JSON out, scoped to your organization.
Generate a token in Dispatch, then send it as a bearer header. There is no SDK to install and no handshake to negotiate.
# List open work orders in your org
curl -s "https://cmms.turnwrk.com/api/v1/dispatch/work-orders?status=open&limit=20" \
-H "Authorization: Bearer hf_admin_YOUR_TOKEN"
# Create one
curl -s -X POST "https://cmms.turnwrk.com/api/v1/dispatch/work-orders" \
-H "Authorization: Bearer hf_admin_YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"propertyId":"prop_123","title":"Dishwasher not draining","type":"plumbing"}'In Dispatch, open Settings → API Tokens, name the token and pick its role — admin, PM or technician. The value is shown exactly once and stored only as a hash, so copy it into your secret store there and then.
Every request carries Authorization: Bearer <token>. A Firebase ID token works too, if you are calling from something already signed into Turnwrk — the same endpoints accept both.
A token is pinned to the organization that created it, and admin and PM queries are scoped to that org server-side — nothing you send can widen it. Technician tokens are the deliberate exception: someone who works for two operators sees their own assigned jobs across both, because that is how one person with two employers actually works. Callers using a Firebase ID token pick an org with an x-org-id header instead.
401 if the bearer header is missing or the token was revoked, 403 if the role is not allowed on that route or the token has no org, 400 if the body is malformed, 500 if something broke on our side. Each is JSON with an error field.
Ten operations across six resource groups. Roles are enforced per route — an admin token reaches all of it, a PM or technician token only its own slice.
List the properties in your org, and patch occupancy — whether a unit is occupied right now and who the current guest is. That flag is what keeps maintenance from knocking on an occupied door. Admin role.
List work orders with filters for status, property and page size, or create one from a property id, a title and a type. Priority and description are optional. Admin role.
Bulk-push bookings for a date range from an external provider, with optional property profiles alongside them. This is the same endpoint our own booking sync uses. Admin role.
List the mappings between your external property ids and Turnwrk properties, then ingest, update, or create-and-map in one call — so your ids stay yours and nothing has to be matched by name. Admin role.
A PM-scoped token reads the work orders for the properties that PM owns, and nothing else. Read-only on the documented surface. One limit to design around: the query covers at most 30 properties, so a PM above that count gets a partial list rather than an error — filter by propertyId if your portfolio is larger.
A technician-scoped token lists the work orders assigned to that technician — across every operator they work for — and patches a work order status, provided they are the assigned technician on it. Enough to drive Turnwrk jobs from a field-service system you already run.
Dispatch serves more routes under /api/v1 than the reference documents. The undocumented ones exist to serve our own apps, they change when those apps change, and they are not a contract with anyone. Build against what the spec lists and your integration keeps working; build against something you found by inspecting network traffic and it will break without warning.
If you need something the spec does not cover, tell us what the integration is. We would rather add it to the contract than have you depend on an accident.
The ones in the published reference: properties, work orders, booking sync, property mappings, plus the property-manager and technician endpoints. Ten operations in total. Anything else you see under /api/v1 powers our own apps and is not part of the public contract — treat it as private.
The spec is browsable, the token takes a minute to create, and there is nobody to ask permission from first.