Developer experience
The Best Developer Experience in Freight
Warp obsesses over developer experience the way Stripe, Vercel, and Supabase do. REST API with structured JSON. CLI that works in any terminal. Webhooks that arrive in real time. Documentation that AI tools can read. Error messages that tell you what went wrong. Test mode for development. All inclusive pricing that is predictable.
REST API · CLI · Webhooks · Structured JSON · Test mode · AI readable docs
Why developer experience matters in freight
The best developer tools do not just work. They make you want to use them. Stripe did not win payments by being cheaper. Stripe won by making the integration so clean that developers chose it over every alternative. Vercel did not win deployment by being faster. Vercel won by making deployment feel effortless.
Freight has never had that. Freight APIs are afterthoughts bolted onto portal first platforms. The data comes back in EDI or SOAP. The error messages are cryptic. The documentation assumes you already know the system. Test mode does not exist. Integration takes months, not hours.
Warp is building the opposite. Every design decision starts with the developer. If the API is confusing, we fix the API. If the error message does not help, we rewrite the error message. If the docs are unclear, we rewrite the docs. Developer experience is not a feature at Warp. It is the product.
Seven principles of Warp DX
1. Structured JSON
Not EDI. Not SOAP. Not proprietary.
Every request and response is JSON with documented field names, types, and enums. No mapping EDI segments to your data model. No parsing XML namespaces. Your code reads the response like any other API.
2. CLI
Ship from your terminal.
The Warp CLI works in any terminal. Quote, book, and track freight from the command line. Pipe output to jq. Use it in shell scripts. Run it in CI/CD pipelines. No portal required.
3. Real time webhooks
Not batched EDI updates.
Register webhook URLs and receive events the moment they happen. Every scan event, GPS update, status change, and exception alert. Pushed to your system in real time. Not batched once or twice a day.
4. AI readable docs
Claude Code can figure out the API.
The documentation is written so AI coding tools can understand the API from the docs alone. Explicit field names. Enum values listed. Request and response examples for every endpoint. Claude Code, Cursor, and Codex can all build integrations from the docs.
5. Helpful error messages
Standard HTTP status codes.
Every error response tells you what went wrong, which field caused it, and what to fix. Standard HTTP status codes: 400 for bad requests, 401 for auth, 404 for not found, 422 for business logic. Not cryptic EDI acknowledgment codes.
6. Test mode
Simulate without moving freight.
Develop and test your integration without moving real freight. Simulate quotes, bookings, tracking events, and webhook delivery. Switch to production when you are ready. No special sandbox environment. Same API, same endpoints.
7. Predictable pricing
Not a maze of surcharges.
All inclusive per pallet pricing. The price you see at quote time is the price you pay. No fuel surcharges. No accessorial surprises. No terminal handling charges. Your code can trust the quoted price.
Five minutes to your first quote
This is the complete flow from zero to a freight quote. One curl command. One response. No SDK installation, no OAuth flow, no portal login.
curl: get a freight rate
curl -X POST https://api.wearewarp.com/api/v1/freights/quote \
-H "Content-Type: application/json" \
-H "apikey: YOUR_API_KEY" \
-d '{
"pickupDate": ["2026-04-07"],
"pickupInfo": { "zipCode": "90210" },
"deliveryInfo": { "zipCode": "10001" },
"listItems": [{
"name": "Retail goods",
"length": 48, "width": 40, "height": 48,
"sizeUnit": "in",
"totalWeight": 800, "weightUnit": "lb",
"quantity": 2, "packaging": "pallet"
}]
}'200 Response
{
"data": {
"quoteId": "01HG9W6CMAWHNWTVXDKW9QYFS9",
"carrierCode": "WTCH",
"carrierName": "Warp Technology",
"serviceLevel": "standard",
"transitDays": 4,
"totalCost": 625.00,
"pickupWindow": { "from": "08:00", "to": "17:00" },
"deliveryWindow": { "from": "08:00", "to": "17:00" }
}
}Warp DX vs. traditional freight platforms
Traditional freight platform
- -Data format: EDI 204/214/210 or SOAP XML
- -Integration time: 3 to 6 months
- -Error messages: cryptic EDI acknowledgment codes
- -Updates: batched EDI files, once or twice daily
- -Test mode: none, test on production
- -Documentation: PDF manuals, requires phone call to explain
- -Pricing: base rate + fuel + accessorials + terminal fees
- -Access: web portal first, API is an afterthought
Warp
- -Data format: structured JSON, every field documented
- -Integration time: hours to days
- -Error messages: HTTP status codes + field level details
- -Updates: real time webhooks, sub second delivery
- -Test mode: full simulation, same API endpoints
- -Documentation: AI readable, Claude Code can parse it
- -Pricing: all inclusive per pallet, no surcharges
- -Access: API first, dashboard is a client of the API
Built for AI agents
The next generation of freight procurement will be handled by AI agents, not humans clicking through portals. Warp is built for this future today. Every endpoint returns structured JSON with explicit field names and enum values. AI agents can quote, compare rates, book shipments, track deliveries, retrieve invoices, and download documents without human intervention.
The Warp CLI works inside AI coding tools like Claude Code, Cursor, and Codex. An AI agent can run warp quote to get rates, warp book to confirm a shipment, and warp track to check status. The output is structured JSON that the agent can parse and act on.
Warp also publishes a machine readable reference at wearewarp.com/llms-full.txt that gives AI tools the complete API reference in a single read. This is not a gimmick. It is how Claude Code learns the Warp API and builds integrations from scratch.
Agent workflow: quote to proof of delivery
POST quoteGet rate
Returns quoteId
POST bookingBook shipment
Returns shipmentId, trackingNumber
POST trackingTrack status
Returns status, location, events
GET {orderId}Get invoice
Returns line items, totals
GET {orderId}Get BOL/POD
Returns document URLs
What the API connects you to
The Warp API is not just a quoting tool. It connects you to a physical freight network: 20,000+ local 3rd party carriers operating 9,000+ box trucks and cargo vans across 50+ cross dock facilities and 1,400+ LTL lanes in 12 markets. Every carrier dispatched through the Warp driver app with live GPS, scan events, and proof of delivery.
Frequently asked questions
Does Warp have a REST API?
Yes. Warp exposes the full freight lifecycle as a REST API with structured JSON. Quote, book, track, get invoices, and retrieve documents. Base URL: https://api.wearewarp.com/api/v1. Auth via API key header.
Does Warp have a CLI?
Yes. The Warp CLI lets you quote, book, and track freight from any terminal. It works in CI/CD pipelines, shell scripts, and AI coding tools like Claude Code and Cursor.
Can AI tools use the Warp API?
Yes. Every endpoint returns structured JSON with explicit field names and enum values. AI agents can quote, book, track, and settle freight without human intervention. The documentation is written so AI tools like Claude Code can figure out the API from the docs alone.
What data format does the API use?
Structured JSON everywhere. No EDI. No SOAP. No proprietary formats. Every request and response is JSON with documented field names, types, and enums. Standard HTTP status codes for errors.
Is there a test mode?
Yes. Warp provides a test mode for development so you can simulate quotes, bookings, and tracking without moving real freight. Switch to production when you are ready.
Freight should feel like Stripe, not like EDI.
REST API. CLI. Structured JSON. Real time webhooks. Test mode. Documentation that AI tools can read. The best developer experience in freight.
REST API · CLI · Webhooks · Structured JSON · 20,000+ carriers