Provider connections, APIs and webhooks

Push a local job status to a provider

Understand status mapping after local transitions.

Audience: Courier operations staffPermission: Courier: EditModule v2.0.0
Exact navigationAdmin Area → Courier & Logistics → Jobs → Open job → Change Status

What this guide covers

Understand status mapping after local transitions. The instructions below follow the supplied module’s controller, form and model rules, including server-side validation and downstream effects.

Exact step-by-step process

  1. Change the job through a valid local transition.
  2. Allow provider push.
  3. Review provider sync/submission evidence.

Fields, choices and supported possibilities

acceptedACCEPTED
en_route_collectionEN_ROUTE_TO_PICKUP
collectedLOADED
en_route_deliveryARRIVED_TO_DELIVERY
cancelledDECLINED

Code-backed validations and workflow rules

  • Only jobs linked to an external provider/load use provider push.
  • Provider errors do not justify skipping local history.

Expected result and verification

  • The source record, status/history and any downstream notification, provider, POD or finance record should agree after the action.

Security, audit and operational checks

  • Use the exact record and least-privilege role before changing any state.
  • Verify the saved record after every action; a browser message alone is not evidence that every downstream step completed.
  • Use protected document and image routes rather than exposing server filesystem paths.
  • Keep customer, driver, provider, financial and credential data within the authorised workflow.
  • For provider, finance, employment, transport and compliance decisions, follow the organisation’s authorised professional process.
Do not bypass the code flowDo not force database values, invent a status, mark a job completed without signed POD evidence, or expose encrypted credentials to make a screen appear successful.