Getting work in
Raising jobs from another system
When another system should raise the job itself: creating an API key, and where to send your integrator — the reference has the rest.
Last updated 10 August 2026.
Is this the right answer?
This page is for a business already running a system that knows about a fault before a person does — a facilities platform, a building-management system, a property manager's own software — where you would rather that system raised the job directly than have someone re-type it into an email. If that system can send email instead of calling an API, that is the simpler route and needs nobody who writes software: see your own WorkOrders address. This page is for when it can't, or when you would rather it didn't.
Creating a key
An owner or administrator mints one under Settings → API keys. It takes a name — who or what the key is for, so you can tell your keys apart later — an access choice of read and write or read only, and an optional expiry date.
The full key is shown once, at the moment you create it, and never again. Copy it into the other system's settings there and then. If it is lost, there is no way to have it shown back to you — mint a new key and revoke the old one.
Give each system its own key rather than sharing one across two integrations. A key can be revoked at any time from the same screen, and revoking one that several systems share breaks all of them at once, on a day when you only meant to break one.
What to hand your integrator
Once the key exists, the handover is short: send whoever is building the integration to the developer reference, and let them know there is a full OpenAPI 3.1 specification at /developers/openapi.yaml they can import straight into whatever they are building the client with. That is the whole handover — the reference has the endpoints, the request and response shapes, the error codes and the rate limits, and it is kept honest by our own test suite, so it cannot quietly fall out of date.
What it can actually do
In outline, without the reference detail: the other system can raise a job with a subject, a description, who reported it, the site address, an urgency, and its own reference number for that job — so a call about it is answerable on both sides — with files attached inline at the same time. It can read a job back to see where it has got to, and read its timeline to see who did what and when. There is nothing pushed out to the other system; it asks us when it wants to know, and asks again later for whatever has changed since. There is no way to assign, complete or reopen a job through this route, because every one of those movements is recorded against a named person on your team, and a company key has nobody behind it.
Security
A key belongs to your company, not to a person, and it can only ever see your company's own jobs. Read-only exists for exactly the case where a system only needs to check on jobs — a dashboard, a status page for tenants — and giving it a read-only key means it cannot raise or change anything no matter what its own code does. Every key can be revoked on the spot from Settings → API keys, and revoking takes effect on the very next request.