Reference · built on requestConnectorFleet & telematics

Onfleet

Delivery tasks, workers, teams, route plans, and proof of delivery from Onfleet, with webhooks for every task event.

About

Onfleet is last-mile delivery management. Its REST API at https://onfleet.com/api/v2 exposes tasks, workers, teams, hubs, destinations, recipients, containers, route plans, orders, and route optimization. A task carries one destination, one recipient, time windows, and completion details with signatures and photos. Webhooks fire on more than thirty triggers, from taskCreated and taskAssigned to taskArrival, taskCompleted, taskFailed, and predictedTaskDelay.

Through Fibric, an operator reads task state, worker duty status, and completion details, then proposes a new task, an assignment, or a forced completion. You approve; the change is written to Onfleet once, with a record of what changed and how to undo it.

This is a reference listing. It documents what Fibric would read from Onfleet and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Tasks by time range, state, worker, and container through List tasks, paged 64 at a time with lastId
  • Workers, their vehicles, on-duty status, and assigned tasks through the Workers endpoints and the workerDuty trigger
  • Task completion details, including signature and photo attachment ids and completion notes, through the taskUpdated trigger
  • Worker ETA and arrival through the taskEta, taskArrival, taskDelayed, and predictedTaskDelay triggers with a threshold you set
  • Route plans and their lifecycle through routePlanCreated, routePlanStarted, routePlanDelayed, and routePlanCompleted
  • Orders as pickup and dropoff task pairs through the Orders endpoints, including quotes and cancellations
  • Team Auto-Dispatch and route optimization results through autoDispatchJobCompleted and routeOptimizationJobCompleted

Proposed actions

  • Target capability: propose a new task with destination, recipient, completeAfter, completeBefore, and requirements through Create task
  • Target capability: propose a task assignment to a worker or team container, or an unassignment
  • Target capability: propose a forced completion with completionDetails through POST /tasks/{taskId}/complete
  • Target capability: propose an order cancellation or update through the Orders endpoints
  • Target capability: propose a route plan and the tasks added to it through Create Route Plan and Add Tasks to Route Plan

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Attach proof to the order

    taskUpdated carries signature and photo attachment ids under completionDetails. The operator matches the task to the order and proposes the proof record for the customer file.

    With Delivery Proof

  • Warn the recipient before arrival

    taskEta and taskArrival fire when the worker is inside your threshold. The operator proposes the message and the channel, and records what was sent.

    With ETA Notice

  • Recover a failed delivery

    taskFailed arrives with the task and its failure notes. The operator proposes a re-delivery task with a new window or a pickup at the hub for a dispatcher to approve.

    With Missed Delivery

  • Rebalance an overloaded route

    routePlanDelayed and predictedTaskDelay show a plan that will not finish. The operator proposes moving tasks to an on-duty worker with capacity.

    With Route Overflow

Requirements

  • An Onfleet organization and an administrator who can create API keys in the dashboard
  • Webhook endpoints that answer Onfleet's validation request and check the X-Onfleet-Signature header
  • The Enterprise plan for Route Optimization and Custom Task Templates
  • A separate organization for testing, arranged with Onfleet support
Authentication
An organization API key created by an administrator in the dashboard API section, sent by HTTP basic authentication with the key as the username and a blank password.

Limits

  • No more than 20 requests per second across all of an organization's API keys; a 429 comes first, then a temporary ban
  • List tasks returns up to 64 tasks per page and requires a from time in Unix time
  • A single webhook targets a single trigger
  • taskCreated does not fire when a task is cloned; taskCloned does

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Onfleet ↗

Questions and answers

How are webhooks authenticated?
Each POST carries an X-Onfleet-Signature header: an HMAC with SHA-512 over the raw body using your webhook secret, a hexadecimal string from Configuration, API & Webhook, Show Secret. Compare your computed digest with the header. Validation is a separate handshake when the webhook is created.
What is the request rate limit?
20 requests per second across all of your organization's API keys. Exceeding it returns a 429 and can lead to a temporary ban. X-RateLimit-Limit and X-RateLimit-Remaining headers report the window and what is left. Onfleet recommends webhooks over polling and the batch endpoint for many tasks.
How do I list tasks?
Call List tasks with a required from time in Unix time and optional to, state, worker, containers, completeBeforeBefore, and completeAfterAfter filters. Completed tasks match on completion time, others on creation time. Each page returns up to 64 tasks; keep paging while lastId is present.
Ask about Onfleet

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.