WardenIQ API

Pricing intelligence for the system you already use.

Your TMS already has the load data. WardenIQ has the win/loss history and the pricing intelligence. This API lets you stitch them together so your operators see the smarter number without leaving the screen they already work in.

Why use this API

Every freight brokerage already has a TMS, a load board, spreadsheets, or some combination. Operators don't want another tool to check. They want pricing intelligence inside the workflow they already use.

The WardenIQ API turns that into reality:

Pull lane intelligence from any system. Call GET /api/integrations/insights/lane with an origin, destination, and equipment type. Get back: win probability signals, a 4-signal score (harmonic, integral, derivative, cross-correlation), historical stats (quotes, wins, losses, win rate, months active), plain-English signals (strong/heating/reliable/aligned), and a ready-to-display summary. Drop any of those fields into your quoting screen and your operators get WardenIQ's intelligence without switching apps.
Get instant markup + win probability at a specific rate. Call GET /api/integrations/insights/markup with a proposed rate and get back: win probability at that exact rate, a suggested sweet-spot rate derived from your historical wins, the full rate band (floor/median/ceiling), and a plain-English verdict. Use it for inline pricing coaching, pre-flight sanity checks, or bulk auto-quoting.
Close the feedback loop when you book a carrier. When your TMS confirms a booking, POST the booked truck cost back via /api/integrations/tms/shipment-update. WardenIQ updates the canonical lane record, re-runs the learning loops, and the intelligence you pull on the next quote reflects the latest actuals. This is how you stop losing data to manual entry friction.
Audit every API call. Every hit on /api/integrations/* is logged with caller, IP, body hash, response code, and latency. GET /api/integrations/audit surfaces recent activity so you can debug integrations or monitor for anomalies.

Who this is for

These docs are for engineers building an integration — typically:

A freight brokerage's in-house TMS development team
A commercial TMS vendor wanting to offer WardenIQ pricing intelligence as an add-on module to their customers
An operations team building internal tooling (Zapier, Make, n8n, custom scripts) that needs to read or write WardenIQ data

If you're a freight broker using the WardenIQ dashboard or Outlook add-in, you don't need any of this — those tools are self-contained.

High-level flow

Broker receives an RFQ.
Your TMS (or WardenIQ's Outlook add-in) parses it and creates a quote.
Before sending the quote, your TMS calls GET /api/integrations/insights/lane to pull WardenIQ's intelligence on this specific origin/destination/equipment. Display the signals inline so the operator sees the smarter markup.
Broker sends the quote through WardenIQ (or your TMS).
Broker wins the quote and books a carrier in your TMS.
When the booking is confirmed, your TMS POSTs the booked truck cost + carrier info to /api/integrations/tms/shipment-update, keyed by lane_ref.
WardenIQ updates the canonical record, invalidates cached lane scores, and feeds the actual margin into the learning loops.
The next time you call /api/integrations/insights/lane on a similar lane, the intelligence is sharper because it's been trained on your real carrier costs.

Design principles

Canonical data model. request_lanes is the single source of truth. Every write flows through the same canonical helper so side effects (score invalidation, feedback loops, audit logs) are consistent regardless of whether the call came from a human in the UI, the Outlook add-in, or your TMS webhook.
Provenance tracking. Every writable field is tagged with a source label (human, tms, csv_import, etc.) so you can audit who wrote what and roll back by source if needed.
Idempotent writes. Endpoints tolerate replays. If your TMS webhook delivers twice, the end state is the same.
Tenant-scoped isolation. Service tokens are tied to a specific tenant. No cross-tenant data exposure is possible even by mistake.
Defense in depth. Write endpoints require both a service token and an HMAC signature. A leaked token alone is not sufficient to poison your data — an attacker would also need the signing secret, which never travels over the wire.

Base URL