← Joblogic integration

Joblogic integration patterns

Joblogic already holds the schedule, the engineers, and the asset register. An agent sitting next to it is not there to replace any of that — it's there to turn signals into scheduled work and to write what it learns back where the office and the engineer will actually see it.

Two patterns cover most of it.

Pattern 1 — signal in, job out

Something elsewhere says a machine is in trouble: a sensor reading, a monitoring alert, an inbound email, a tenant's message. The job of the agent is to decide whether that warrants field work, and if so to create it correctly the first time.

signal → find the site → find the asset → create the job → book the visit
  1. joblogic_search_sites — resolve the location. Search by name, postcode, or reference, scoped to a customer if you know it.
  2. joblogic_search_assets with site_id — find the specific piece of equipment. Serial number and asset number are the reliable keys; descriptions are not.
  3. joblogic_search_jobs with site_unique_id — check for an open job against the same site or asset before creating a duplicate. This step is the difference between a useful integration and a noisy one.
  4. joblogic_create_job — with the customer, site, description, type, and priority. Statuses and types are tenant-configured, so read the available values rather than assuming them.
  5. joblogic_create_visit — schedule an engineer against the job. joblogic_search_engineers gives you the workforce to pick from.

Both write steps require approval, so a human sees the job before it lands.

Pattern 2 — actuals and evidence out

The other direction: work has happened, and the record of it needs to reach the system that cares — an ERP, a client's portal, a compliance report.

completed jobs → costs and forms → summarise → write back
  1. joblogic_search_jobs with a completion date range and a status filter.
  2. joblogic_get_job for the detail — engineer, dates, tags, order number.
  3. joblogic_search_forms_logbook / joblogic_get_job_forms — the certificates and checklists completed on site. For compliance-driven trades (fire, gas, electrical) this is the actual deliverable.
  4. joblogic_api_get against /JobCost for labour, materials, travel, and subcontractor lines when you need the cost picture.
  5. joblogic_create_note — put the summary, the reference number, or the discrepancy back on the job so it isn't only in a report someone has to open.

Writing back is the point

The temptation is to build a read-only dashboard. Resist it. A contractor's office staff live in Joblogic; anything an agent concludes that stays outside Joblogic is a thing they have to be told twice.

  • joblogic_create_note attaches findings to the record they're about.
  • joblogic_update_job_status keeps Joblogic aligned when another system is the one moving the work along.

Reaching the rest of the API

Only the core entities have dedicated tools. Joblogic exposes far more — purchase orders, stock and stock adjustments, timesheets, contracts and PPM contracts, subcontractors, vehicles, part libraries, per-entity attributes.

  • joblogic_api_get for reads.
  • joblogic_api_call for POST/PUT/DELETE.

Both take a path under /api/v1 and add the tenant id automatically. The endpoint shape is regular (see the data model guide), so POST /api/v1/{Entity}/GetAll is a safe first guess for any entity in the reference.

Things that will bite

  • 403 on everything is the IP allowlist, not permissions.
  • PUT replaces the whole record. Read it, modify it, send all of it back.
  • Page size must be 5–50. Anything else is a 400.
  • All datetimes are UTC. A local-time value is accepted and silently misread — in a scheduling system, that shows up as visits on the wrong day.
  • 100 requests/minute. Page deliberately; don't fan out across sites in parallel without a limit.