// Integration · 10 min read
PRIVATE AI THAT PLUGS INTO YOUR TMS.
Most ops directors hear "private AI" and assume it means yanking out their TMS. It doesn't. The integration patterns we use add a private AI layer alongside your TMS — reading what's there, writing back where it's safe, never replacing it. Here are the patterns that work.
By the Marapone team · Updated 2026
The four roles AI plays alongside a TMS
Across MercuryGate, McLeod, SAP TM, Oracle OTM, BluJay, and the long tail of regional TMS platforms, the AI layer plays one of four roles. Pick the right one and the integration is straightforward.
1. Reader. AI ingests TMS data, reasons over it, surfaces insights in its own UI. The TMS is unchanged. Lowest integration risk.
2. Annotator. AI reads, then writes back notes, flags, or status fields that the TMS understands. Operators see annotations inside the TMS they already use.
3. Pre-filler. AI drafts records (e.g. invoice dispute documents, carrier scorecards) and writes them as drafts into the TMS for human approval.
4. Trigger. AI watches TMS events and kicks off workflows in the AI layer (e.g. invoice arrived → audit; carrier on-time slipped → alert).
The integration cost goes from 1 to 4 in roughly that order. Most useful AI layers do roles 1 and 4 with optional 2.
MercuryGate
MercuryGate's REST API is mature and well-documented. We typically ingest shipments, quotes, invoices, and POD records via standard endpoints with an OAuth-scoped service account. Write-back of audit notes goes through the shipment annotation API.
Common gotcha: the rate-limit on bulk shipment fetch is conservative for older accounts. Use the delta endpoints, not full-table polls, or you'll spend a week arguing with your account manager.
McLeod (LoadMaster, PowerBroker)
McLeod's preferred path is direct database access via a read-only SQL Server view layer that their integration partners can spin up. We've also done it via their REST API where exposed.
Most North-American brokerages running McLeod can get to a working ingest pipeline in 2-3 days, including the read-only DB user and the schema mapping. Write-back is typically into the freight notes table, scoped to a specific user account that's clearly marked as the AI service.
Tip:
Stamp every AI-written note with a tag like [ai-audit] at the start. Operators can filter for them, and you'll never wonder which notes were human and which weren't.
SAP TM
SAP TM is the heaviest of the bunch. The cleanest pattern is OData services exposed via the SAP Gateway, with shipment, freight order, and freight settlement data flowing out and audit results flowing back into Forwarding Charge Documents (FCDs) as draft adjustments.
In practice the integration takes 2-3 weeks for a SAP-native shop with an experienced Basis admin who can authorize the OData services. The SAP side moves slower than ours, so book the joint working session early.
Oracle TMS (OTM)
OTM exposes integration via standard XML web services and a flexible event subscription model. Shipment, rate, and invoice ingest is straightforward. Write-back into shipment status updates is supported and well-documented.
The thing to watch for: OTM environments are often heavily customized. Don't assume your tenant matches the documented schema. Our pattern is to ingest first, then layer the customizations as they're discovered.
BluJay (E2open)
Tender + invoice ingest is achievable via their REST endpoints, but each tenant tends to require a small amount of custom work because the data model is configurable. Plan for 1-2 weeks of integration work, mostly in the schema-mapping layer.
The pattern that works for all of them
Regardless of TMS:
- Read-only first. Ingest a representative sample. Validate the AI output offline.
- Then a UI-only AI surface. Operators see AI output in our UI; nothing writes back to the TMS yet.
- Then optional write-back, scoped tightly. Specific fields, specific records, clearly tagged as AI-authored.
- Eventually, automation triggers. Once trust is established, the AI layer can act on TMS events without human prompting.
Skipping a step is the most common cause of stalled integrations. Going from "no AI" to "writes invoices into the TMS" without the intermediate stages turns into a six-month change-management problem.
When the TMS doesn't have an API
Some smaller or regional TMS platforms still don't expose APIs cleanly. Two practical workarounds:
Email-based ingest. Most TMS can email reports on a schedule. We pull from a dedicated mailbox and parse. Slower, less elegant, works.
Database read replicas. If you have a SQL-accessible TMS, a read-only replica is often the lowest-friction path even if the TMS technically has an API.
TELL US YOUR TMS.
WE'LL MAP THE INTEGRATION.
Send us the platform you run and your top 3 workflows. We'll write back a one-page integration plan within 24 hours.
Get an Integration Plan →