Programmable freight
Programmable freight is the application of API-first infrastructure design to freight movement. Quoting, booking, tracking, document retrieval, and invoicing are exposed as REST endpoints, MCP tools, and CLI commands instead of phone calls, EDI files, and broker portals. The freight network itself runs the same way it always has — trucks, cross-docks, drivers, fuel — but every operation that previously required a human handoff is now a function call.
Why it matters
Stripe made payments programmable in 2010 and changed how every SaaS company processes money. Plaid did it for bank data. Twilio did it for messaging. Freight stayed closed off behind EDI, brokers, and PDFs for an extra decade because the operational complexity (carriers, fuel, weather, cross-docks) felt incompatible with a simple API. Programmable freight is the bet that the right abstraction layer lets developers ship code that books real LTL or FTL with the same ergonomics as creating a Stripe charge.
When to use it
Programmable freight is the right framing when your team is building software that needs to move physical goods — DTC brands shipping pallet quantities, marketplaces with multi-vendor inventory, B2B SaaS that adds shipping as a feature, AI agents that orchestrate operations. The alternative — EDI integration, broker relationships, manual quote-then-book workflows — costs more and ships slower than wiring up a freight REST API.
How Warp thinks about it
Warp is the programmable-freight network. Public REST API with 25+ endpoints, the first MCP server for booking real freight, a CLI agent, OpenAPI 3.1 spec, an open Postman collection, and self-serve API keys in 3 minutes at /agents/account. The entire stack is documented and discoverable. No sales call required, no demo, no broker relationship.
Frequently asked questions about programmable freight
What is programmable freight?
Programmable freight is the application of API-first infrastructure design to freight movement. Quoting, booking, tracking, document retrieval, and invoicing are exposed as REST endpoints, MCP tools, and CLI commands instead of phone calls, EDI files, and broker portals. The freight network itself runs the same way it always has — trucks, cross-docks, drivers, fuel — but every operation that previously required a human handoff is now a function call.
Why does programmable freight matter in freight?
Stripe made payments programmable in 2010 and changed how every SaaS company processes money. Plaid did it for bank data. Twilio did it for messaging. Freight stayed closed off behind EDI, brokers, and PDFs for an extra decade because the operational complexity (carriers, fuel, weather, cross-docks) felt incompatible with a simple API. Programmable freight is the bet that the right abstraction layer lets developers ship code that books real LTL or FTL with the same ergonomics as creating a Stripe charge.
When should you use programmable freight?
Programmable freight is the right framing when your team is building software that needs to move physical goods — DTC brands shipping pallet quantities, marketplaces with multi-vendor inventory, B2B SaaS that adds shipping as a feature, AI agents that orchestrate operations. The alternative — EDI integration, broker relationships, manual quote-then-book workflows — costs more and ships slower than wiring up a freight REST API.
How does Warp handle programmable freight?
Warp is the programmable-freight network. Public REST API with 25+ endpoints, the first MCP server for booking real freight, a CLI agent, OpenAPI 3.1 spec, an open Postman collection, and self-serve API keys in 3 minutes at /agents/account. The entire stack is documented and discoverable. No sales call required, no demo, no broker relationship.