Get customers
Answer customers
Work for you
Reach people
Give agents tools
Run and ship
Manage customers, items, jobs and calendar events; read orders, payments and proposals
List customers. Requires scope `customers:read`.
4 fields
Retrieve a customer. Requires scope `customers:read`.
1 field
Create a customer. Requires scope `customers:write`. `firstName` is required (and cannot be blank).
12 fields
Update a customer. Requires scope `customers:write`. Only supplied fields are changed.
13 fields
List items. Requires scope `items:read`.
5 fields
Retrieve an item. Requires scope `items:read`.
Create an item. Requires scope `items:write`. `customerId` (must exist) and `name` are required. For `lawnCare`, `location` is also required.
Update an item. Requires scope `items:write`. Only supplied fields are changed. Supply `customerId` to move the item to a different customer.
List products/services. Requires scope `products:read`.
6 fields
Retrieve a product/service. Requires scope `products:read`.
List categories. Requires scope `products:read`. Ordered the way the app lists them (by `num`), not newest-first.
3 fields
List jobs. Requires scope `jobs:read`. Note: ordering by `start`/`end` only returns jobs that have that field set (i.e. scheduled jobs).
Retrieve a job. Requires scope `jobs:read`.
Create a job. Requires scope `jobs:write`. Send line items as product/service references + quantities; the server looks up prices, embeds the products, and computes the invoice subtotal/tax/total. A sequential `num` is assigned. Requires a customer, an `industry`, at least one `itemId`, and at least one line item. A job's work is always tracked per item, so the invoice comes back with the line items grouped under `invoice.items` — keyed by item ref — rather than as a flat `invoice.lineItems` array. On a job with one item every line item belongs to it; on a job with several, each line item must name its `itemId`, and every item needs at least one line item. A `field` job is performed on site, so it also needs a `location`: send one, or omit it and the customer's location is copied onto the job. It is rejected only when neither exists. A `location` sent on a `shop` job is ignored. If `name` is omitted it defaults to the joined names of the referenced items (e.g. the vehicle names). Jobs are always created `unpaid`. To record an invoice that was already collected, create the job and then record the money with `POST /v1/payments`, which settles the invoice and derives the payment status. When importing history, set `completedAt` to the original completion date along with `status: completed` so the job reports in the right period. The earnings and profit reports only count completed jobs, so `completedAt` without that status is rejected rather than silently leaving the revenue out of every figure. Likewise `canceledAt` requires `status: canceled` in the same request. New jobs pick up the account's default reminders, but the immediate 'job scheduled' confirmation message is suppressed by default so imports can't mass-message customers — pass `deployScheduledMessage: true` to send it (future-dated jobs only, and only when the account's scheduled-message auto-deploy preference is on).
21 fields
Update a job. Requires scope `jobs:write`. Only supplied fields are changed. If `lineItems` is supplied the invoice is recomputed; otherwise the existing invoice is preserved. Because a job's line items are grouped under the item they are for, `itemIds` and `lineItems` move together: send the line items alongside any change to `itemIds` (they are rebuilt against the new set, and items dropped from the job lose their line items). Payment status is derived from the invoice and cannot be set here; record money with `POST /v1/payments`. A supplied `location` replaces the job's address outright (the derived `formattedAddress`, `geoPoint` and `timeZone` are all recomputed). On a job that is or becomes `field` and has no location yet, the customer's is copied onto it; the request is rejected only when neither exists. Changing `type` to `shop` clears the job's location.
List events. Requires scope `events:read`.
7 fields
Retrieve an event. Requires scope `events:read`.
Create an event. Requires scope `events:write`. `name`, `start`, and `end` are required.
List orders. Requires scope `orders:read`.
Retrieve an order. Requires scope `orders:read`.
List payments. Requires scope `payments:read`. Filter by `jobId`, `orderId`, or `subscriptionId` to find the payments applied to a specific record.
8 fields
Retrieve a payment. Requires scope `payments:read`.
List proposals. Requires scope `proposals:read`. Proposals are read-only via the API. Use `createdAfter` or `updatedAfter` (Unix ms) to poll for new/changed proposals cheaply instead of paging through the full history; supplying either overrides `orderBy` to match the filtered field.
Retrieve a proposal. Requires scope `proposals:read`.
List users. Requires scope `users:read`. Returns every team member on the account (not paginated). Users are read-only via the API.
