Reference

Lookups

Reference data — the IDs the gateway will accept on job and site operations.

All lookups respond with { "items": [...] }. Results are scoped to what your key can see and capped at 100 items per call. Lookups require the jobs:read scope.

These IDs change rarely (only on operator action). Cache the results in your application — refresh on a daily schedule, or on demand if a lookup fails. See Rate limits for why this matters.

GET/v1/customers

The customers your key can act on. Use the ID to filter jobs or attach a site to a customer on create.

{ "items": [{ "id": "245715", "name": "Acme" }] }

GET/v1/sites

Sites under your customers. Use the ID as `site=` on POST /v1/jobs. To add or edit a site, see POST and PATCH /v1/sites.

{ "items": [{ "id": "3065756", "name": "Acme Depot — Unit 3/24 Brand Dr" }] }

GET/v1/projects

Projects you may attach to a job. Use the ID as `project=` on POST /v1/jobs.

{ "items": [{ "id": "1052232", "name": "Test Project #1" }] }

GET/v1/job-types

Available job types. Use the ID as `job_type=` on POST /v1/jobs.

{ "items": [{ "id": "29400", "name": "Installation" }] }

GET/v1/job-statuses

Available job statuses. Use IDs as `?status=` on GET /v1/jobs to filter by status.

{ "items": [{ "id": "68392", "name": "Tentative" }] }

GET/v1/custom-fields

Custom-field names you may send under `custom_fields` on POST / PATCH /v1/jobs.

{ "items": [{ "external_name": "scope_of_work", "fi_field_id": "349661", "job_type_id": null }] }