Freight API for SAP and Oracle: Connect Once, Ship Everywhere

Why enterprise teams pick the wrong freight integration

The default path inside SAP and Oracle is to wire each carrier in directly. SAP TM ships with adapters for the largest LTL and parcel carriers. Oracle OTM has its own service provider catalog with its own rate sheet model. Both expect that you will pick eight to twenty carriers, configure tariffs for each, set up EDI 204 tendering and EDI 214 tracking with each, and maintain those connections for the life of the ERP.

The cost shows up in three places. First, the integration build. Each carrier connection takes a developer four to eight weeks plus a transportation analyst to validate accessorials, fuel surcharges, and discount structures. Eight carriers compounds into a year of work. Second, ongoing maintenance. Carriers change tariff schemas, add fuel matrices, and deprecate API versions. Every change is a ticket against the SAP TM team. Third, coverage gaps. The carriers you integrated cover lanes A through M. The lanes that come up next quarter, the ones M through Z, are out of scope until someone writes another adapter.

The Warp freight API collapses this work. One REST integration covers LTL, FTL, box truck, and cargo van across 20,000+ carriers. Tariff refresh, accessorial logic, fuel calculation, and carrier vetting all happen inside the Warp network and surface to your ERP as a single all-inclusive rate. You write one adapter, not twenty.

The Warp freight API at a glance

Five endpoints cover the freight lifecycle from rate request to settled invoice. The same endpoints power the Warp customer dashboard, the Warp CLI, and the Warp MCP server, so feature parity between your ERP integration and the Warp portal is enforced by design.

SAP integration: TM, S/4HANA, and the BAdI path

For shippers running SAP Transportation Management (SAP TM 9.x or the embedded SAP TM in S/4HANA), the cleanest integration is to register Warp as a custom carrier in the SAP Carrier Selection routine. The Warp adapter sits behind the standard /SCMTMS/CARRIER_SEL BAdI and returns a Warp quote whenever the carrier selection logic asks for a rate. Your existing freight units, freight orders, and forwarding orders flow through unchanged. Only the rate source switches.

The integration shape is straightforward. Inside the BAdI, build the Warp quote payload from the SAP freight unit (origin and destination location IDs, package units, and weight), call POST /api/v1/freights/quote, and map the response back into the SAP rate structure. Persist the Warp quoteId as a custom ZZ_WARP_QUOTE_ID attribute on the freight order header so that the booking step can reference it without a second quote round-trip.

For S/4HANA shippers without SAP TM, the same endpoints run from a custom Z-program triggered by the outbound delivery (VL01N or VL10A) or from the SAP Integration Suite (formerly Cloud Platform Integration). The Cloud Connector handles outbound HTTPS to api.wearewarp.com; the iFlow does the JSON marshalling. Tracking events flow back through the same iFlow as inbound webhook calls and update the delivery status via the standard BAPI.

Oracle integration: OTM, Fusion Cloud SCM, and EBS

For Oracle Transportation Management (OTM) shippers, Warp registers as a service provider in the OTM service provider catalog. The OTM rate inquiry workflow calls a custom rate offering that proxies to the Warp quote endpoint. Returned rates appear in the OTM shipment build screen alongside any other service providers configured for the lane, so transportation planners pick Warp the same way they pick a direct carrier today. The Warp shipmentId writes back to the OTM shipment SHIPMENT_GID as a reference attribute.

Oracle Fusion Cloud SCM customers integrate through Oracle Integration Cloud (OIC) using the REST adapter. The Warp endpoints map onto the Fusion Cloud Shipment business object: a quote response populates the planned cost, a booking response writes the tracking number, and webhook events update the shipment status workflow through the OIC inbound REST trigger. For Oracle EBS shippers, the same OIC pattern applies with the EBS Shipping Execution module as the destination.

Across all three Oracle stacks, the design principle is the same: Warp is one service provider that internally aggregates 20,000+ carriers. Your transportation planning, accounting, and visibility surfaces in OTM, Fusion, or EBS stay in place. Only the rate source consolidates.

The five endpoints your enterprise needs

You can run a complete enterprise freight program against five endpoints. Quote returns rates. Booking confirms a load. Tracking returns status. Invoices return settled costs for AP reconciliation. Documents return BOLs and PODs for archival. Multi-stop FTL is a sixth endpoint for shippers running consolidated outbound or pool distribution programs.

Code samples: quote, book, track, document

Every example below works against production with a valid API key. Pass your ERP shipment reference as the Idempotency-Key header on every mutating call so middleware retries do not create duplicate quotes or duplicate bookings.

Quote. Build the request from your SAP freight unit or Oracle OTM shipment. Persist quoteId on the ERP shipment object.

// SAP TM or Oracle OTM calls Warp for live multi-mode rates
const response = await fetch('https://api.wearewarp.com/api/v1/freights/quote', {
  method: 'POST',
  headers: {
    'apikey': process.env.WARP_API_KEY,
    'Content-Type': 'application/json',
    'Idempotency-Key': erpShipmentRef // your ERP shipment ID
  },
  body: JSON.stringify({
    pickupInfo:   { zipCode: '60601', city: 'Chicago',   state: 'IL' },
    deliveryInfo: { zipCode: '30301', city: 'Atlanta',   state: 'GA' },
    listItems: [{
      name: 'Pallet - SKU 4471',
      length: 48, width: 40, height: 52, sizeUnit: 'in',
      totalWeight: 1100, weightUnit: 'lb',
      quantity: 4, packaging: 'pallet', stackable: false
    }],
    pickupDate: ['2026-04-28']
  })
});

const { data } = await response.json();
// data.quoteId, data.totalCost (all-inclusive), data.transitDays
// Persist quoteId on the SAP/Oracle shipment object as ZZ_WARP_QUOTE_ID

Booking. Reference the persisted quoteId. Warp returns the carrier shipment ID and tracking number. Write both back to the ERP record.

// SAP TM accepts the rate, Warp tenders to the carrier
const booking = await fetch('https://api.wearewarp.com/api/v1/freights/booking', {
  method: 'POST',
  headers: {
    'apikey': process.env.WARP_API_KEY,
    'Content-Type': 'application/json',
    'Idempotency-Key': `book-${erpShipmentRef}`
  },
  body: JSON.stringify({
    quoteId: shipment.zzWarpQuoteId,
    pickupInfo:   { zipCode: '60601', city: 'Chicago', state: 'IL',
                    street: '500 W Madison St', contactName: 'Dock 12', phone: '3125550144' },
    deliveryInfo: { zipCode: '30301', city: 'Atlanta', state: 'GA',
                    street: '1100 Spring St NW', contactName: 'Receiving', phone: '4045550199' },
    listItems: shipment.lineItems
  })
});

const { data } = await booking.json();
// data.shipmentId, data.trackingNumber, data.orderId
// Write back to SAP TFK shipment record or Oracle OTM Shipment.OBJECT_ID

Webhook receiver. Map Warp event statuses onto your ERP shipment status workflow. Verify the signature header on every request before processing.

// Warp pushes status events to your SAP/Oracle middleware
// Register https://erp.example.com/warp/webhook in the Warp dashboard
app.post('/warp/webhook', verifySignature, async (req, res) => {
  const event = req.body;
  // event.shipmentId, event.status, event.location, event.eventTimestamp

  switch (event.status) {
    case 'pickupSuccessful':
      await sapTm.updateShipmentStatus(event.shipmentId, 'PICKED_UP');
      break;
    case 'inRouteToDelivery':
      await sapTm.updateShipmentStatus(event.shipmentId, 'IN_TRANSIT');
      break;
    case 'delivered':
      await oracleOtm.closeShipment(event.shipmentId, event.podUrl);
      break;
    case 'exception':
      await orbitAlertToSlack(event); // Orbit fires before SLA breach
      break;
  }

  res.status(200).send('OK');
});

Document retrieval. Pull BOL and POD into SAP DMS or Oracle WebCenter Content for archival.

// Pull POD/BOL into SAP DMS or Oracle WebCenter Content
const docs = await fetch(
  `https://api.wearewarp.com/api/v1/freights/documents/${orderId}`,
  { headers: { 'apikey': process.env.WARP_API_KEY } }
);

const { data } = await docs.json();
// data.bolUrl, data.podUrl (signed S3 URLs, 24h TTL)
// Stream into SAP archive or Oracle UCM with the ERP shipment as parent

Webhook events: real-time freight status into your ERP

Polling the tracking endpoint every five minutes wastes API calls and lags reality. Webhook events push status changes to your middleware as they happen. Register one HTTPS endpoint per environment in the Warp dashboard. Warp signs every payload with HMAC-SHA256 using your shared webhook secret. Verify the X-Warp-Signature header before processing.

Event types map cleanly onto SAP TM and Oracle OTM shipment status transitions. The most common events: quoteCreated, shipmentBooked, carrierAssigned, pickupScheduled, pickupSuccessful, inRouteToDelivery, delivered, exception, and invoiceReady. Each payload includes the Warp shipmentId, the event timestamp in ISO 8601, and event-specific data (location for transit events, document URL for delivery events, exception code and Orbit-recommended action for exception events).

Webhook delivery is at-least-once with exponential backoff. If your endpoint returns a non-2xx response, Warp retries on a doubling schedule (1, 2, 4, 8, 16, 32 minutes) for up to 24 hours. Idempotent handlers are required: process the same event ID more than once should be a no-op. Failed deliveries surface in the Warp dashboard webhook log so your team can replay or skip events that hit a poison pill in your middleware.

Authentication, rate limits, idempotency

Security and compliance: SOC 2, PII, data residency

Warp is SOC 2 Type II audited. The audit covers security, availability, processing integrity, and confidentiality controls across infrastructure, application, and operational practice. Reports are available under NDA from your enterprise rep. Data in transit uses TLS 1.2 or higher with HSTS. Data at rest is encrypted with AES-256. API keys are scoped, rotatable, and never log in plaintext anywhere in the platform.

PII handling is minimized by design. The freight payload includes pickup and delivery contact name, phone, and address. No payment card data, no consignee SSN, no employee identifiers. Contact data is retained for the life of the shipment plus the audit retention window required by carrier and DOT regulation, then purged. Access controls inside Warp follow least-privilege principles enforced through SSO and group-based permissioning.

For shippers with data residency or BAA requirements (HIPAA-adjacent freight, controlled goods, government), the enterprise solutions team scopes a custom deployment plan during onboarding. Standard production traffic runs in US-based AWS regions with multi-AZ failover. The full security questionnaire (CAIQ-style, plus carrier-specific addenda) is available on request.

Rollout plan: pilot lane to production in 30 days

The standard enterprise rollout is four weeks. Week one: sandbox API key issued, pilot lane selected (one origin, one destination, one mode), middleware quote and booking flow built against sandbox. Week two: pilot lane runs in shadow mode where SAP or Oracle still tenders to incumbent carrier but Warp returns a parallel quote for cost comparison. Week three: pilot lane goes live, real bookings flow through Warp, tracking events post back to ERP, AP team validates the first invoices end to end. Week four: rollout to remaining lanes in scope, incumbent carrier deprecated for those lanes, Orbit alerting wired into Slack or PagerDuty.

Solutions engineering pairs with your integration developer for the first two weeks. Office hours, code review, and Slack support are standard. Most integrations ship faster than 30 days; the timeline is the safe upper bound, not the average.

Frequently asked questions