How to Integrate a Last-Mile Delivery API With Your ERP or TMS: A Step-by-Step Guide for 2026

The Scenario This Guide Solves

An enterprise retailer promises a two-hour delivery window at checkout. The order lands in the OMS. Overnight, a batch file moves it to the TMS. In the morning, someone exports a spreadsheet and imports it into the last-mile system. The route is planned against yesterday’s picture, the vehicle leaves, and when a stop runs long there is no path back: the OMS still shows the original window, the customer sees the original ETA, and nobody learns the promise broke until it has.

Nothing in that chain is misconfigured, and no amount of careful coding fixes it. It is a batch architecture doing exactly what batch architectures do, and the promise was unkeepable from the moment it was made.

Most logistics API integration guides address carrier and parcel APIs, which is a genuinely different problem. This guide covers last-mile delivery API integration specifically: connecting an ERP or TMS to a delivery orchestration platform so that orders, dispatch decisions, execution events, and delivery confirmation move continuously in both directions.

Why Last-Mile Delivery API Integration Is Different

Carrier APIs Versus Delivery Orchestration APIs

A carrier API is transactional. You request rates, you create a shipment, you get a label, you poll or subscribe for tracking milestones. The data model is the shipment, and the carrier decides everything about how it moves.

A delivery orchestration API is operational. The objects are orders, routes, vehicles, drivers, capacity, constraints, exceptions, and proof of delivery. Crucially, calling it invokes a decision: submitting orders causes planning and allocation to happen, and the response is a plan rather than an acknowledgement. That difference drives everything else about the integration, because a system that makes decisions needs richer input and produces consequential output.

The Four Data Flows That Must Be Real-Time

1. Order ingestion. Orders reach the delivery platform with everything planning needs: address and validated geocode, time window, service requirements, item attributes, access constraints, and priority. Late or thin order data produces plans that were wrong before dispatch.
2. Dispatch event. The plan and its assignments flow outward: which driver or carrier, which sequence, which committed window. The ERP and OMS need this because it is the moment the promise becomes real.
3. Tracking event. Execution flows back continuously: departure, arrival, progress against plan, exceptions raised. This is the flow most often left as polling, and the one where latency costs most.
4. Completion and proof of delivery. Outcome, timestamp, geolocation, and captured evidence flow back into the systems of record for customer service, dispute resolution, and settlement.

Also Read: 5 Critical Shipping API Integration Categories for Enterprise Logistics in 2026

What Breaks When These Are Batch

Dispatch happens against a stale order set, so late orders miss the plan entirely. ETAs communicated to customers derive from transit assumptions rather than execution, so they drift. Re-routes are impossible because the platform cannot see a change it was never told about. And proof of delivery arrives in the ERP hours later, so customer service answers disputes without evidence they already own.

Reference Architecture

The common shape:

ERP or OMS ? (orders, master data) ? middleware or iPaaS, optional ? (REST, webhooks) ? delivery orchestration platform ? (dispatch, sequence) ? driver app ? (execution events, POD) ? back through the same path.

Middleware is optional and worth a deliberate decision. It earns its place when you have many endpoints, need transformation and monitoring in one layer, or have a standing enterprise integration platform. It adds a hop, and therefore latency and a failure point, so for a single ERP-to-platform integration direct is often better.

Prerequisites and Last-Mile Delivery API Integration Planning

Establish which systems are actually in scope. Last-mile delivery API integration scope is set here, not later. Your ERP or TMS determines most of the timeline. SAP, Oracle, Microsoft Dynamics 365, NetSuite, and Blue Yonder each have different integration idioms and different connector maturity across vendors, and a heavily customized instance of any of them will dominate the schedule regardless of the delivery platform.

Inventory the data objects to be exchanged. At minimum: orders, shipments or consignments, routes, driver or vehicle assignments, tracking events, exceptions, and proof of delivery. For each, decide direction, trigger, and owner of truth. The last one prevents the most common post-go-live argument.

Decide event-driven versus polling per flow. Webhooks for anything where latency changes an outcome, which is tracking events, exceptions, and dispatch confirmations. Polling as a fallback where a counterparty cannot push, and for reconciliation sweeps to catch anything a webhook dropped. Running both, with webhooks primary and a periodic reconciliation poll, is the pragmatic enterprise pattern.

Audit data quality before writing code. Address quality and geocoding accuracy, master data consistency for customers and locations, and status vocabulary differences across systems. This work is not optional and it is where unplanned weeks come from.

Confirm the sandbox. Before signature, ideally. You want realistic test data, the ability to simulate failure states, and documented fixtures.

Also Read: How to Evaluate API Integrations for Your Logistics Tech Stack (TMS, ERP, WMS, and Carrier Connectivity)

Step-by-Step Last-Mile Delivery API Integration Sequence

The last-mile delivery API integration sequence below is platform-agnostic and holds across delivery orchestration platforms. Specific endpoint paths, object schemas, and event names come from your platform’s API documentation.

Step 1: Authenticate

Expect OAuth 2.0 for platform APIs, with client credentials flow for server-to-server integration. Obtain credentials for sandbox and production separately, confirm token lifetime and refresh behaviour, and establish secret rotation before go-live rather than after the first expiry incident. Where a counterparty requires it, mutual TLS may be in scope.

Step 2: Map Order Data to the Platform’s Order Object

The highest-value step and the one where most defects originate. Map every field your ERP holds to the platform’s order schema, and pay particular attention to four categories that planning depends on and ERPs often hold poorly:

• Location: full address plus validated geocode. If your ERP does not hold a geocode, decide now whether validation happens at intake, in middleware, or in the platform.
• Time: requested window, service-level commitment, and any customer availability constraint.
• Handling: item weight, volume, count, temperature requirement, fragility, assembly requirement.
• Access: stairs, lift booking, doorway constraint, parking or dock restriction, site delivery hours.

Document unmapped fields explicitly. Every planning constraint your ERP knows and does not send becomes a dispatcher workaround later.

Step 3: Configure Dispatch Triggers

Decide what causes planning and dispatch to run: a schedule, an order-volume threshold, a manual release, or continuous evaluation as orders arrive. Enterprise operations usually combine a scheduled wave with continuous evaluation for same-day injections. Define also what happens to orders arriving after the final wave, because that rule is otherwise made ad hoc by whoever is on shift.

Step 4: Subscribe to Event Webhooks

Subscribe to the execution lifecycle: dispatched, en route, arrived, delivered, failed, plus exception and re-plan events. For each subscription, implement:

• Signature verification on every payload, with timestamp validation to block replay
• Idempotent handling, keyed on an event identifier, so a retried delivery does not double-post a status
• Retry tolerance and dead-letter capture, so a transient outage on your side does not silently lose events
• A replay path for recovering a missed window

Step 5: Map Proof of Delivery Back

Return outcome, timestamp, geolocation, signature or photo reference, recipient detail, and failure reason codes into the ERP against the original order record. Decide where captured images live and how long they are retained, and treat recipient data as personal data with a retention policy rather than an attachment.

Step 6: Build Error Handling and Retry Logic

Assume every call fails eventually. Requirements: idempotency keys on all writes, exponential backoff with jitter on retries, a dead-letter queue with alerting, and a reconciliation job comparing order state across both systems on a schedule. That reconciliation job is the single most valuable piece of unglamorous code in the integration, because it catches the drift nobody notices until month-end.

Step 7: Test End to End Before Going Live

Unit test each endpoint, then run realistic end-to-end scenarios in the sandbox: a normal delivery, a failed attempt with reattempt, a mid-route cancellation, a same-day injection, an exception requiring reassignment, and a webhook outage with replay. Then run parallel against live volume before cutting over.

ERP-Specific Last-Mile Delivery API Integration Considerations

Last-mile delivery API integration idioms differ by ERP platform. What follows describes each ERP’s own integration style; connector coverage from any given delivery platform must be confirmed with that vendor against your specific instance and version.

SAP S/4HANA and SAP TM

SAP environments typically integrate through OData services for modern REST-style exchange, with IDoc and BAPI patterns persisting in older or heavily customized landscapes, and SAP’s own integration middleware often sitting in the path. Delivery-relevant objects usually centre on outbound deliveries, shipments, and their status updates. Two practical realities dominate SAP projects: customization depth in your instance drives the timeline more than anything the delivery vendor controls, and status semantics between SAP’s document flow and a delivery platform’s execution states need explicit mapping rather than assumed equivalence.

Oracle Transportation Management

OTM is built around event-based messaging and integration through its own XML-based interfaces, with a well-established pattern of inbound and outbound message flows. Delivery orchestration integration typically attaches at the shipment level, with execution events flowing back as status updates. Confirm how the delivery platform’s event model maps to OTM’s expected message structures, since the translation layer is where most of the work sits.

Microsoft Dynamics 365

Dynamics integrates through Dataverse and OData APIs, with Power Platform connectors available for lower-code integration paths. That makes Dynamics environments often faster to connect than SAP or OTM, though the same field-mapping discipline applies. Where a Power Platform connector exists it can carry a meaningful share of the integration, and where it does not, custom API integration is straightforward against Dataverse.

Also Read: Open API Architecture for Logistics Integration at Scale

How to Evaluate a Last-Mile Delivery API Before You Sign

A last-mile delivery API integration checklist. Score each item as evidenced, claimed, or absent.

• REST API with full CRUD coverage on the order lifecycle
• Webhook support for asynchronous events, with documented retry, dead-letter, and replay behaviour
• Signature verification and documented secret rotation on inbound webhooks
• Idempotency guarantees on all write operations
• Self-serve sandbox with failure-state simulation, available before contract signature
• Named production integrations with your specific ERP or TMS, at a reference you can call
• Contractual API uptime, published rate limits, and pagination behaviour
• Documentation quality and a version and deprecation policy
• A clear iPaaS path where no pre-built connector exists
• Support model and escalation path for integration issues

Items six and eight are the ones that most often turn out weaker than the sales conversation implied.

Where Locus Fits

Locus is the world’s first Decision-Intelligent, Agentic Transportation Management System, and it is the last-mile delivery API integration target for exactly the pattern this guide describes: an ERP or OMS connected to a platform that plans, dispatches, tracks, and re-optimizes rather than one that records shipments.

Architecturally, three properties matter for integration. Locus holds a canonical operational model, so status semantics are normalized rather than passed through, which removes the translation problem that otherwise multiplies with each connected system. Its decisioning runs against 250+ real-world constraints, which is why the order-mapping step above matters so much: constraints your ERP sends become constraints the plan honours. And carrier reach through ShipFlex connects a 1,000+ carrier network with 160+ carriers pre-integrated, so multi-carrier execution is a mapping rather than a per-carrier integration project.

Indonesia’s leading FMCG distribution brand integrated Locus as an end-to-end distribution planning and visibility platform, replacing manual planning and dispatch, and achieved 100% proof-of-delivery digitization, 100% track and trace on a single platform, a 34% distance reduction per order, and a 9% volume utilization increase from the first month after go-live. A retail enterprise consolidating six legacy systems onto Locus reduced manual dispatch effort by more than 80% while sustaining 99%+ on-time delivery and reaching break-even inside year one. At scale: 1.5B+ deliveries orchestrated for 360+ enterprise customers across 30+ countries at 99.99% uptime.

Also Read: API Integrations for Logistics Platforms: From Fragmented Connectivity to Intelligent Orchestration

ShipFlex is featured as a Representative Vendor in the 2026 Gartner Market Guide for Multi Carrier Parcel Management Solutions.

Learn more, visit locus.sh