← Joblogic integration

Joblogic data model & endpoint map

Joblogic is the system of record for a service contractor. Its API exposes

roughly seventy entity groups, but they are built from a small, repeated shape —

learn the shape once and the whole surface follows.

The core objects

Customer ──< Site ──< Asset          who you bill, where work happens, what you maintain
                │
                └──< Job ──< Visit   the work, and each engineer attendance
                        │
                        ├──< Job Cost     labour, materials, travel, mileage, subcontractor
                        ├──< Form         certificates and checklists completed on site
                        ├──< Quote        priced work awaiting approval
                        └──< Invoice      what gets billed

• Customer — the billing entity. Name, address, account number, references.
• Site — a physical location belonging to a customer. Jobs happen here and

• Asset — the equipment register: make, model, serial, location, install and

hang off assets, which makes this the table that matters most for

maintenance-contract work.

• Job — reactive or planned (PPM) work at a site. Has a job number, status,

completion, complete).

• Visit — an engineer's scheduled attendance against a job. Dispatch lives

• Engineer — the mobile workforce, with working hours and on-call state.

Around that core sit parts and part libraries, suppliers and subcontractors,

purchase orders, stock and stock locations, timesheets and paybands, contracts

and PPM contracts, vehicles, tags, and per-entity attribute libraries.

The repeated endpoint shape

Nearly every entity group exposes the same five operations:

Search is a POST rather than a GET because the filter sets are large enough

to overflow a URL.

Two ids per record

Every record has both:

• UniqueId — a GUID, stable and safe to store.
• Id — an auto-increment integer, and the one users see in the Joblogic UI.

Search results return both. Detail endpoints are less consistent: some return

the GUID as Id and the integer as IntId. When you store a reference, store

the GUID; when a human quotes a number, it's the integer.

Paging

Every search shares one request envelope:

{
  "SearchTerm": "",
  "TagIds": "",
  "IncludeInactive": false,
  "PageIndex": 1,
  "PageSize": 10
}

and one response envelope:

{ "Items": [ ... ], "TotalCount": 0, "PageIndex": 1, "PageSize": 10 }

range the request is rejected with a 400. Read TotalCount to decide whether to

page on rather than guessing.

Entity-specific filters are extra fields on the same body: jobs take

take CustomerId.

Updates replace, they don't merge

Joblogic does not support PATCH. A PUT replaces the entire resource, so the

only safe update is read-modify-write: fetch the record, change the fields you

mean to change, and send every property back. Omitting a property clears it.

Statuses are tenant-configured

Job statuses, types, categories, and priorities are per-contractor

configuration, not a fixed enum. Two tenants will not agree on the set. Resolve

them at runtime — there are GetAll endpoints for job status, job type, job

category, and priority — rather than hard-coding a list.