Ellipse Gradient for Header

Onfleet Integration Guide

Connect Onfleet delivery operations with enterprise systems through its REST API, selected webhook events, and secure API-key authentication.

Onfleet integration options at a glance

Onfleet’s primary integration mechanism is its REST API, which supports operational objects such as Tasks, Workers, Teams, Hubs, Recipients, and Administrators. Onfleet also provides webhook-style notifications for selected operational events, including task lifecycle changes, although coverage is event-specific rather than universal. Martini can consume the REST API, receive Onfleet callbacks through an exposed endpoint, and orchestrate validation, mapping, business rules, retries, and downstream updates. API-key authentication is used over HTTPS and should be stored in Martini secrets. For larger synchronizations, Martini can schedule controlled REST retrieval, pagination, checkpointing, and reconciliation without assuming an undocumented bulk API.

Integration pointSupported by Onfleet?Common use casesHow Martini supports it
REST APIsYesCreate, update, and retrieve Tasks, and query Workers, Teams, Hubs, Recipients, Administrators, and related operational data.Martini can consume the Onfleet REST API from workflows, map request and response data, expose reusable internal APIs, and handle errors and retries.
Webhooks / outbound callbacksLimitedReceive selected task and workforce lifecycle notifications, such as assignment, start, arrival, completion, or failure events.Martini can expose a REST endpoint or webhook-consuming workflow, validate callbacks, normalize events, apply rules, and route them downstream.
AuthenticationYesAuthenticate API requests with an Onfleet API key supplied through HTTP authentication over HTTPS.Martini can store the key as a secret, apply it to REST requests, and keep credentials out of workflow definitions and logs.
Scheduled synchronizationYesRetrieve Tasks, Workers, Teams, Hubs, or Recipients for reconciliation, historical synchronization, or data not covered by webhook events.Martini can schedule workflows, paginate documented endpoints, persist checkpoints, control concurrency, and reconcile source and target state.
File / attachment handlingLimitedProcess documented completion metadata or media references such as photos, signatures, or notes when returned by task responses.Martini can transform documented URLs or metadata and transfer content through an appropriate external file or object-storage system; a general Onfleet file API is not confirmed.
Bulk / async / batch APIsNot confirmedLarge-volume processing should not assume a general-purpose Onfleet bulk API without confirming the current reference.Martini can still orchestrate controlled batches around documented REST endpoints using scheduling, pagination, throttling, and bounded retries.
Database / analytics accessNoNo direct Onfleet database or general-purpose analytics database access is confirmed.Martini can retrieve data through the REST API and write transformed results to a supported database or intermediary data platform.
SDKsNot confirmedClient libraries may exist, but SDK availability is not required for the primary REST-based integration approach.Martini uses standards-based HTTP API consumption, avoiding an SDK prerequisite and preserving reusable workflow logic.

How Onfleet exposes data and business events

Onfleet REST APIs

Onfleet’s REST API is the principal programmatic integration interface for creating, updating, and retrieving Tasks and querying Workers, Teams, Hubs, Recipients, Administrators, and related operational objects. It is suitable for order-to-delivery orchestration, scheduled synchronization, reconciliation, and API-led access.

Martini implementation pattern

Martini implementation pattern: a workflow receives an upstream request or scheduled trigger, authenticates with an API key stored in a secret, calls the documented Onfleet endpoint, validates and transforms the response, applies business rules, and writes the result to downstream systems. The workflow can persist identifiers and checkpoints and handle transient failures without assuming a bulk API.

Implementation sequence

Receive an order, API request, or scheduled trigger
Authenticate the Onfleet REST request with a protected API key
Validate required delivery, recipient, and timing fields
Create, update, or retrieve the required Onfleet object
Map and transform the response into the target data model
Apply business rules and persist identifiers or checkpoints

Onfleet webhook events

Onfleet supports webhook-style notifications for selected operational events. Coverage is event-specific and may include assignment, start, arrival, completion, failure, or other documented task lifecycle changes; it should not be treated as a universal stream for every object or state transition.

Martini implementation pattern

Martini implementation pattern: an exposed REST endpoint receives the callback, validates the request according to the current Onfleet webhook security model, acknowledges promptly, and invokes workflow logic to deduplicate, normalize, enrich, and route the event. Longer downstream work can be separated from the callback receipt path, with processing outcomes retained for replay and troubleshooting.

Implementation sequence

Receive the Onfleet callback at a Martini endpoint
Validate the payload and applicable webhook security controls
Record the event and Task identifiers for deduplication
Acknowledge the callback promptly
Normalize the documented event into an internal delivery event
Apply state and exception rules before updating downstream systems

Common Onfleet integration patterns

Pattern 1: Create Onfleet Tasks from commerce orders

When to use this pattern

Use this pattern when paid or fulfilled orders from a commerce application must become delivery work in Onfleet. The workflow validates address, recipient, delivery window, and task requirements before creating a Task, then correlates the Onfleet identifier with the source order so retries do not create duplicates.

Integration direction
Shopify
Martini
Onfleet
Example Mapping
Onfleet FieldCanonical FieldTarget Field
order.idsourceOrderIdTask metadata or correlation field
shipping_addressdeliveryDestinationTask destination
customer contactrecipientContactTask recipient
delivery instructionsdeliveryNotesTask notes
Martini implementation pattern

Martini receives the order through an API or scheduled workflow, validates required fields, checks the source-to-Task correlation store, maps the payload, creates the Task through the REST API, and persists the returned identifier. Validation failures are routed separately from transient API failures, which use bounded retries.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • secrets management
  • error handling

Pattern 2: Propagate delivery events to customer systems

When to use this pattern

Use this pattern when customer-facing or order-management applications need timely delivery status without repeatedly polling every Task. Supported Onfleet webhook events are normalized and routed to systems such as Salesforce, Zendesk, or a commerce platform, with state checks protecting against duplicate or out-of-order callbacks.

Integration direction
Onfleet
Martini
Salesforce
Example Mapping
Onfleet FieldCanonical FieldTarget Field
task.iddeliveryTaskIdDelivery reference
task statusdeliveryStatusCase or custom object status
completion detailscompletionEvidenceDelivery outcome
event timestampstatusChangedAtStatus change time
Martini implementation pattern

Martini receives the callback, validates and records the event, checks prior processing and current state, enriches the event with stored order context, and updates the target system. Duplicate events become no-op updates, while failed downstream calls enter retry or exception handling.

Martini capabilities used
  • APIs
  • workflow triggers
  • data mapping
  • business rules
  • idempotency
  • error handling

Pattern 3: Synchronize workforce and operational data

When to use this pattern

Use this pattern when an internal operations application, workforce system, or reporting platform requires a normalized view of Workers, Teams, Hubs, or Tasks. Scheduled retrieval is appropriate for historical loads, reconciliation, and data not covered by webhook notifications.

Integration direction
Onfleet
Martini
Database
Example Mapping
Onfleet FieldCanonical FieldTarget Field
worker.idworkerIdworker_id
worker statusworkerStatusstatus
team.idteamIdteam_id
task completion detailscompletionDatacompletion_json
Martini implementation pattern

A scheduled Martini workflow retrieves documented resources with pagination and controlled concurrency, transforms nested Onfleet structures into a canonical model, writes results to a database or data platform, and persists a checkpoint. Rate-limit responses and network failures are retried with bounded backoff, followed by reconciliation for incomplete pages.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination orchestration
  • data transformation
  • database integration
  • retry handling

Pattern 4: Orchestrate delivery exceptions

When to use this pattern

Use this pattern when failed, delayed, or otherwise exceptional Tasks require coordinated action across orders, support, notifications, or operations. Business rules classify the exception, prevent repeated notifications, and determine whether to update the originating order, open a support case, or route an operational alert.

Integration direction
Onfleet
Martini
Zendesk
Example Mapping
Onfleet FieldCanonical FieldTarget Field
task statusexceptionTypeTicket classification
task.iddeliveryReferenceTicket external reference
recipient contactcustomerContactTicket requester
task notesexceptionContextTicket description
Martini implementation pattern

Martini receives a supported event or retrieves status during reconciliation, validates and classifies the Task state, enriches it with source-order context, and updates Zendesk or another target. The workflow records the decision, retries transient failures, and sends persistent failures to an operational exception path.

Martini capabilities used
  • webhook consumption
  • scheduled workflows
  • business rules
  • data enrichment
  • duplicate detection
  • monitoring

Applications commonly integrated with Onfleet

Onfleet commonly participates in commerce, fulfillment, customer-service, ERP, shipping, and reporting architectures. These are integration patterns rather than evidence of native Onfleet or Martini connectors; exact mappings, permissions, and event coverage should be confirmed during solution design.

Application Scenario Direction Martini Pattern
Shopify Create Onfleet Tasks from paid or fulfilled orders and return delivery progress to the commerce workflow. Shopify → Martini → Onfleet Martini receives order or fulfillment data, validates delivery details, maps the order to an Onfleet Task, stores the returned Task identifier, and processes supported Onfleet events back into the order workflow.
Salesforce Synchronize delivery status, customer-facing delivery events, and exceptions with Accounts, Contacts, Cases, or custom objects. Onfleet → Martini → Salesforce Martini receives selected Onfleet events or performs scheduled retrieval, normalizes Task and Recipient data, applies status rules, and updates the appropriate Salesforce objects with duplicate protection.
Zendesk Create or update support tickets when deliveries fail, are delayed, or require customer-service intervention. Onfleet → Martini → Zendesk A Martini webhook workflow validates Onfleet events, classifies delivery exceptions, enriches them with order context, and creates or updates Zendesk tickets while recording processing state.
WooCommerce Convert WooCommerce orders into Onfleet delivery Tasks and return delivery progress to the commerce workflow. WooCommerce → Martini → Onfleet Martini consumes WooCommerce order data, maps recipient, destination, timing, and notes fields to an Onfleet Task, and routes supported status events back to WooCommerce.
BigCommerce Coordinate order fulfillment and delivery tracking between BigCommerce and Onfleet. BigCommerce → Martini → Onfleet Martini orchestrates order retrieval or callbacks, validates delivery information, creates or updates Onfleet Tasks, and synchronizes confirmed lifecycle changes to BigCommerce.
ShipStation Coordinate shipment and fulfillment information with last-mile delivery Tasks. ShipStation → Martini → Onfleet Martini transforms shipment data into Onfleet Task payloads, correlates shipment and Task identifiers, and routes completion or exception information to the relevant fulfillment workflow.
NetSuite Synchronize sales-order fulfillment, shipment, and delivery completion information with Onfleet. NetSuite → Martini → Onfleet Martini consumes or exposes REST endpoints for fulfillment events, maps NetSuite shipment data to Onfleet Tasks, and reconciles completion and exception states using persisted identifiers.
Power BI Load normalized Onfleet Task, Worker, and completion data for operational reporting. Onfleet → Martini → Power BI Martini periodically retrieves Onfleet data, applies checkpointed pagination and normalization, writes results to an intermediary data platform, and makes the curated dataset available to Power BI.

How to build a Onfleet integration in Martini

Objective

Establish authenticated access to Onfleet and any target applications without exposing credentials in workflows or logs.

Instructions in Martini

  • Create environment-specific Onfleet API keys as appropriate
  • Store the API key in Martini secrets or secure environment configuration
  • Configure HTTPS REST requests using the authentication format required by the current Onfleet reference
  • Restrict logging of authorization headers and sensitive payload fields

Objective

Select an event-driven, API-led, or scheduled entry point based on the required latency and Onfleet event coverage.

Instructions in Martini

  • Use a Martini API or webhook endpoint for supported Onfleet callbacks
  • Use an upstream API request for order or fulfillment submission
  • Use a scheduler for reconciliation, historical loads, and unsupported event coverage
  • Define acknowledgment and asynchronous processing behavior for callbacks

Objective

Acquire documented Onfleet data while accounting for event-specific webhooks, pagination, rate limits, and checkpoints.

Instructions in Martini

  • Validate incoming callback structure and security controls
  • Call documented REST endpoints for Tasks, Workers, Teams, Hubs, or Recipients
  • Implement endpoint-specific pagination and persist synchronization checkpoints
  • Apply controlled concurrency and backoff for rate-limit or transient responses

Objective

Coordinate the end-to-end integration flow, including correlation, enrichment, routing, and downstream calls.

Instructions in Martini

  • Correlate source orders, Onfleet Tasks, and event identifiers
  • Separate validation errors from authentication, network, and server failures
  • Route delivery events and exceptions according to business rules
  • Use reusable workflow logic for common API and error-handling behavior

Objective

Convert Onfleet payloads and source application models into stable canonical and target-specific structures.

Instructions in Martini

  • Map destinations, recipients, timing, notes, assignments, and completion details explicitly
  • Normalize status values and timestamps for downstream consumers
  • Preserve required identifiers and selected unmapped fields
  • Handle documented media references without assuming a general Onfleet file API

Objective

Persist or publish the result to commerce, customer-service, ERP, database, reporting, or notification systems.

Instructions in Martini

  • Create or update target objects using stable external identifiers
  • Persist the Onfleet Task identifier with the source transaction
  • Make writes idempotent where callbacks or retries can repeat
  • Record successful checkpoints only after target processing completes

Common Onfleet data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
TasksRepresent delivery or pickup work, including destinations, recipients, notes, timing, assignment, and completion details.Shopify, Salesforce, Zendesk, WooCommerce, BigCommerce, NetSuite, reporting platformsMartini validates and maps source fulfillment data into Task payloads, stores Task identifiers, processes lifecycle events, and reconciles state.
WorkersRepresent drivers or other personnel who execute Tasks.Workforce applications, operations platforms, reporting data storesMartini retrieves Workers through REST workflows, normalizes status and assignment data, and synchronizes it on a schedule where required.
TeamsGroup Workers and organize operational responsibility.Operations applications, workforce systems, reporting platformsMartini queries Teams, maps organizational relationships, and applies business rules when routing or reporting operational data.
HubsRepresent physical or logical locations associated with teams and task operations.Dispatch applications, operational databases, reporting platformsMartini retrieves Hubs, transforms location and ownership fields, and maintains a normalized operational view.
RecipientsRepresent delivery recipients associated with Tasks and destinations.Commerce platforms, customer-service systems, order-management systemsMartini validates recipient and contact data, maps it into Task payloads, and minimizes sensitive information in logs and free-text fields.
AdministratorsRepresent Onfleet users or administrative accounts managing the organization.Identity, governance, audit, and reporting systemsMartini can retrieve documented Administrator data where required and apply field-level filtering before downstream synchronization.

Authentication and security considerations

API-key authentication

Onfleet API access uses an API key over HTTPS. Current Onfleet documentation should be checked to confirm the exact HTTP authentication formatting before deployment.

Secret handling

  • Store API keys in Martini secrets or secure environment configuration.
  • Use separate keys for development, testing, and production where appropriate.
  • Do not expose authorization headers in logs, errors, or responses.
  • Rotate keys according to organizational security policy.

Webhook protection

Validate callbacks according to the current Onfleet webhook security model. The exact signing, shared-secret, or verification mechanism should be confirmed before production use.

Operational considerations for Onfleet integrations

Rate limits and pagination

Confirm current Onfleet limits, response headers, pagination parameters, and page sizes. Use controlled concurrency, bounded backoff, and checkpoints for scheduled synchronization.

Idempotency and ordering

Persist source-order, Task, and event identifiers. Webhook deliveries and retries may be duplicated or arrive out of order, so state checks should protect downstream writes.

Data quality

Validate addresses, coordinates, recipients, delivery windows, time zones, and instructions before creating or updating Tasks. Avoid unnecessary sensitive data in free-text notes.

Schema and testing

Treat status values, nested recipient and destination structures, and completion details as integration contracts. Test validation, authentication failures, rate limits, retries, duplicate callbacks, and reconciliation scenarios.

Observability

Record correlation identifiers, checkpoints, processing outcomes, and exception details without logging secrets. Monitor workflow failures and reconcile source shipments against Onfleet Tasks.

Why use Martini instead of scripts or point-to-point integrations?

Orchestration instead of isolated scripts

Martini provides a maintainable workflow layer for receiving Onfleet events, calling REST endpoints, transforming payloads, applying business rules, and coordinating multiple target systems.

Reusable integration logic

Shared API, mapping, validation, retry, and correlation logic can be reused across commerce, support, ERP, database, and reporting workflows instead of being duplicated in point-to-point scripts.

Operational control

Martini supports scheduled and event-driven execution, controlled retries, checkpointing, exception routing, monitoring, and secure environment configuration. This helps teams combine near-real-time Onfleet events with periodic reconciliation.

API-led flexibility

Martini can consume Onfleet’s REST API and expose controlled APIs to internal applications, allowing consumers to depend on a stable integration contract rather than Onfleet-specific request details.

Frequently asked questions

How can Onfleet be integrated with enterprise systems?

Onfleet can be integrated primarily through its REST API and selected webhook-style event notifications. Enterprise workflows can create and retrieve Tasks, query Workers, Teams, Hubs, Recipients, and Administrators, receive documented delivery events, and synchronize results with commerce, customer-service, ERP, database, and reporting systems.

Can Martini integrate with Onfleet?

Yes. Martini can consume the Onfleet REST API and receive selected Onfleet webhook events using secure API-key configuration, workflows, data mapping, business rules, retries, and downstream APIs or databases. A Martini-native Onfleet connector is not verified in the supplied documentation.

Do I need a connector to integrate Onfleet with Martini?

No. A dedicated Onfleet connector is not required. Martini can integrate using Onfleet’s confirmed native mechanisms: REST API requests, selected webhook callbacks, HTTPS, and API-key authentication.

Is there any extra Lonti cost to integrate Onfleet with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Onfleet. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Onfleet, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.

Which Onfleet integration methods should architects use?

Use the REST API for creating, updating, retrieving, and reconciling operational data. Use webhook-style notifications for supported near-real-time events, but confirm current event coverage and security requirements. GraphQL and SOAP APIs are not confirmed or supported for Onfleet, so they should not be assumed.

Are Onfleet events or webhooks available?

Onfleet supports webhook-style notifications for selected operational events, including potentially assignment, start, arrival, completion, or failure states. Coverage is event-specific rather than universal, so scheduled REST reconciliation remains useful for historical data and states not covered by callbacks.

How does Martini synchronize and transform Onfleet data?

Martini can retrieve or receive Onfleet data, map it into a canonical model, apply validation and business rules, and write it to target applications or databases. Scheduled workflows can use pagination and checkpoints, while webhook workflows can normalize events and correlate them with source orders or customer records.

How are Onfleet errors, retries, and duplicates handled?

Martini can separate validation errors from authentication, rate-limit, network, and server failures; retry transient failures with bounded backoff; and route persistent failures to exception workflows. Persisting source-to-Task and event-processing identifiers helps prevent duplicate Tasks and duplicate downstream updates.

Related Martini documentation

Onfleet API

Events

Workflows

Security

Operations

Connect Onfleet with your enterprise systems

Use Martini to build secure, maintainable Onfleet integrations across delivery, commerce, customer-service, workforce, and reporting workflows.

EXPLORE MARTINI
BOOK A DEMO