Build with Warp

Build your own freight TMS with Warp.

Copy a Warp-aware prompt into Claude Code, ChatGPT's Codex, or your preferred coding assistant. It will scaffold the dashboard in read-only mode first, then add a locked booking module users can unlock when they are ready.

AI prompt to build a freight TMS dashboard

Copy the build-your-own-TMS prompt below into Claude Code or ChatGPT Codex. The prompt scaffolds a Next.js dashboard with public Warp rate data, mock bookings, a locked booking module, and a clear upgrade path to live keys. Deploys to Vercel.

Claude prompt to build a TMS for a small shipper

Copy the same prompt below into Claude Code. Pick solo or team mode upfront — solo runs single-user, team adds Auth.js + Postgres + role-gated booking. Both inherit Warp's public quote endpoints and locked booking module.

Get an instant Warp quote →

Warp-ready agent prompt

Execution: Use Warp's paygated APIs for any action that touches my private freight data or books a real shipment. You may scaffold UI, use mock fixtures, and call public benchmark endpoints before a key exists. Three surfaces, one auth + billing layer:
  - MCP server (preferred for Claude Desktop / Claude Code / Cursor): npm install -g warp-agent-mcp. 17 tools: warp_van_quote, warp_box_truck_quote, warp_ftl_quote, warp_ltl_quote, warp_multistop_quote, warp_multistop_book, warp_book, warp_cancel, warp_track, warp_events, warp_list_bookings, warp_lane_history, warp_quote_history, warp_get_invoice, warp_get_documents, warp_rate_card, warp_status.
  - CLI: npm install -g @warpfreight/cli-agent. Same coverage as MCP, JSON output, scriptable.
  - REST API: https://www.wearewarp.com/freight-api and https://www.wearewarp.com/.well-known/openapi.json, Bearer auth.
Live API key required for private data and real booking. Issued in ~3 minutes at https://www.wearewarp.com/agents/account. Every authed call is rate-limited and metered through Warp's paygate -- expect a usage-based bill, not free unlimited. Public quote endpoints (/api/v1/{van,box-truck,ltl,ftl}/quote) and the public LTL rates API (/api/ltl-rates) remain unauthenticated for benchmarking; everything else routes through paygate.

Intent: "I want to build a lightweight TMS dashboard that works before I add a card: public rates, mock data, bookings list placeholders, tracking UI, and a locked booking module. It should support either solo mode (just me) or team mode (multiple users at my company with role-based access). When I am ready, the TMS should give me a clear link to unlock a live Warp booking key, let me paste that key into the server-side environment, and deploy to Vercel with a one-click button."

Context: Warp ships three first-party agent surfaces. (1) REST API documented at https://www.wearewarp.com/freight-api with the public spec at https://www.wearewarp.com/.well-known/openapi.json. The PUBLIC openapi.json is intentionally narrow (quote/book/track + ltl-rates), but the FULL authenticated REST surface is much broader -- the TMS should call these endpoints directly with Bearer auth: POST /api/v1/freight/quote (multi-mode quote), POST /api/v1/freight/book (book a quote), GET /api/v1/freight/track/{shipmentId} (track), POST /api/v1/rebook (re-quote + book a prior lane in one call), POST /api/v1/cancel, GET /api/v1/bookings (recent bookings, max 100), GET /api/v1/lanes (lane history with last consignee + frequency), GET /api/v1/locations (saved pickup/delivery addresses), GET/POST/DELETE /api/v1/load_templates (saved freight profiles -- name, weight, dims, commodity, hazmat), GET /api/v1/quote-history, GET /api/v1/rate-card (negotiated rates per mode), GET /api/v1/events?shipment_id=X (full tracking timeline), GET /api/v1/invoices?order_id=X (invoice URL), GET /api/v1/documents?order_id=X (BOL/POD URLs), POST /api/v1/multistop/quote, POST /api/v1/multistop/book, GET /api/ltl-rates (no-auth benchmarks). Public quote endpoints are also exposed at /api/v1/{van,box-truck,ltl,ftl}/quote without auth for benchmarking. (2) MCP server (recommended for coding assistants): npm install -g warp-agent-mcp exposes 17 of the above as tools to Claude Desktop, Claude Code, Cursor, and any MCP-compatible agent. The 17 MCP tools: warp_van_quote, warp_box_truck_quote, warp_ftl_quote, warp_ltl_quote (quote per mode); warp_multistop_quote, warp_multistop_book (FTL multi-stop); warp_book, warp_cancel, warp_track, warp_events; warp_list_bookings; warp_lane_history; warp_quote_history; warp_get_invoice, warp_get_documents; warp_rate_card; warp_status (validate key). NOTE: locations, load_templates, and rebook are REST-only -- no MCP tool wraps them; call REST directly for those. (3) CLI: npm install -g @warpfreight/cli-agent -- same coverage as MCP. Customer dashboard at customer.wearewarp.com handles user invites/role assignment and email/SMS/Slack notification preferences per lane -- the TMS does NOT need to reimplement these (link out instead). Existing Warp tools you should link to rather than rebuild: BOL generator at /tools/bill-of-lading-template, BOL vault at /tools/bol-vault, batch rating at /tools/batch-rating, freight invoice audit at /tools/freight-invoice-audit. A live booking key is unlocked at https://www.wearewarp.com/agents/account?intent=tms_booking&return_to=%2Fagents%2Fhandoff%2Fbuild-your-own-tms after the user adds a card. Until then, build the TMS with public data, mock fixtures, and a locked booking state. Hosting target is Vercel: the user owns the deploy on their own free or Pro account; Warp does not resell Vercel.

What I need from you:
  1. Ask me two upfront questions: (a) what stack I want (Next.js recommended for the Vercel target; Python/FastAPI, plain HTML, Slack bot, or CLI also fine), and (b) solo mode (single user, no auth) or team mode (multi-user with role-based access). Pick Next.js + solo mode if I'm unsure.
  2. Scaffold the first version with no card and no live key required: public rate data, mock active bookings, mock lane history, mock invoice status, and tracking UI placeholders.
  3. If team mode: add Auth.js (NextAuth) with email magic-link or Google SSO, a Postgres users table (Vercel Postgres or Neon -- both have free tiers), and a role column with three roles: admin (manages users + booking key), booker (can request and confirm bookings), viewer (read-only). Gate /api/v1/freight/book behind role >= booker. Show an /admin/users page that only admins can see for inviting teammates and changing roles. Store the WARP_API_KEY server-side once at the org level, not per-user -- every authorized user books against the same Warp account.
  4. If solo mode: skip auth entirely. The TMS runs as a single-user app with WARP_API_KEY pulled from env. Note that solo mode can be upgraded to team mode later by adding the auth and DB layer.
  5. Add a locked Booking module in the TMS. It should show the future quote -> review -> book flow, but keep the Book button disabled until WARP_API_KEY exists server-side. In team mode, also disable it for users below booker role.
  6. Inside that locked module, include a clear CTA link: https://www.wearewarp.com/agents/account?intent=tms_booking&return_to=%2Fagents%2Fhandoff%2Fbuild-your-own-tms. Label it "Unlock live booking key".
  7. Include an "after unlock" copy block in the TMS with a .env.local snippet (WARP_API_KEY=wak_live_..., plus AUTH_SECRET and DATABASE_URL if team mode) and a short prompt the user can paste back into an assistant: "Add live Warp booking to this TMS using WARP_API_KEY server-side. Quote first, show confirmation, then POST /api/v1/freight/book only after explicit approval."
  8. Show me the minimum API surface for the full version: GET /api/ltl-rates for no-auth benchmarking, POST /api/v1/freight/quote for live quote, POST /api/v1/freight/book for confirmed booking, GET /api/v1/freight/track/{shipmentId} for tracking. For everything beyond quote/book/track, use the MCP server (warp-agent-mcp, 17 tools) -- the public REST surface intentionally stops at quote/book/track.
  9. Wire these existing endpoints to TMS surfaces -- DO NOT reinvent local versions of any of these. From REST (call directly with Bearer auth): GET /api/v1/locations -> address book (do NOT build a separate locations CRUD; this is the canonical store); GET/POST/DELETE /api/v1/load_templates -> saved freight profiles page; POST /api/v1/rebook -> one-click rebook on the recurring-lanes page; GET /api/v1/lanes -> 'recurring lanes' overview with last consignee + ship frequency. From REST or MCP (equivalent coverage): GET /api/v1/quote-history (warp_quote_history) -> quote-history page; GET /api/v1/bookings (warp_list_bookings) -> recent-bookings dashboard; GET /api/v1/invoices (warp_get_invoice) -> invoice viewer (no PDF generation needed -- Warp returns the URL); GET /api/v1/documents (warp_get_documents) -> BOL/POD viewer (Warp generates BOLs and stores PODs server-side -- just render the document URLs, do NOT build upload UI); GET /api/v1/rate-card (warp_rate_card) -> contract-rates display; GET /api/v1/events (warp_events) -> tracking event timeline; GET /api/v1/freight/track/{id} (warp_track) -> single-shipment status. For multi-stop FTL use warp_multistop_quote/book or POST /api/v1/multistop/{quote,book}. For bulk rating, link out to https://www.wearewarp.com/tools/batch-rating instead of building bulk UI. For BOL generation outside the booking flow, link to /tools/bill-of-lading-template. For invoice dispute UX, link to /tools/freight-invoice-audit. For user invites + role assignment + email/SMS/Slack notification preferences, link out to https://customer.wearewarp.com -- the TMS must NOT reimplement notification infrastructure or invite flows beyond Auth.js login.
  10. After the v1 dashboard works, ask me which of these TRUE local-only features to add next. None of these exist in Warp's API or customer dashboard; each requires local DB tables and logic. (1) Audit log -- record every quote/book/cancel inside the TMS with actor (user email), timestamp, and request/response payload. (2) Approval workflow -- hold any booking over a configurable dollar threshold in a 'pending approval' state, send the admin an in-app notice + email, and only call POST /api/v1/freight/book once an admin approves. (3) Cost-center / PO tagging -- attach a PO number, GL code, and project tag to each booking, and roll up spend by tag. (4) Spend dashboard -- aggregate warp_list_bookings + warp_get_invoice into monthly + per-lane + per-mode rollups with CSV export. (5) Webhook forwarder -- a server-side worker that polls warp_events for active shipments every N minutes and POSTs status changes to a user-configured Slack or ERP webhook URL. Implement only what I pick; do not bundle them.
  11. When adding live mode, put the API key only in server-side environment variables. Never expose it in browser JavaScript. In team mode, never expose other users' email or role data to non-admin users.
  12. Generate a README.md with two deploy paths: (1) a one-click "Deploy to Vercel" button using the URL pattern https://vercel.com/new/clone?repository-url=<MY_REPO_URL>&env=WARP_API_KEY,AUTH_SECRET,DATABASE_URL&envDescription=Warp%20booking%20key%20plus%20auth%20secrets&project-name=my-warp-tms (omit AUTH_SECRET and DATABASE_URL from the env list if solo mode), and (2) a manual `vercel deploy` path for users who prefer the CLI. Tell me to push the repo to GitHub first so the clone URL works.

Decision policy:
  - Don't require a card or live key for the first TMS scaffold.
  - Don't write code that bypasses my API key for private data or booking. Authenticate every live request.
  - Don't auto-deploy or auto-run. Show me the code first.
  - For example data, use the public LTL rates API (no auth) and mock fixtures. Use authenticated endpoints only after I unlock a key.
  - Don't book or charge anything automatically. The live flow must quote first, show a confirmation screen, and call /api/v1/freight/book only after explicit approval.
  - In team mode, never let a viewer or booker change roles, invite users, or see the booking key. Admin-only routes must check role server-side, not just hide buttons in the UI.
  - Don't claim Warp resells or manages Vercel. The user owns their Vercel account, billing, and deployment. Warp only provides the freight API the TMS calls.
  - Don't reinvent what Warp's API already provides. Use /api/v1/locations, /api/v1/load_templates, /api/v1/lanes, /api/v1/rebook, /api/v1/quote-history, /api/v1/bookings, /api/v1/invoices, /api/v1/documents, /api/v1/rate-card, /api/v1/events (or their MCP equivalents where one exists) instead of building local equivalents. For BOL generation, batch rating, and invoice audit UI, link out to the existing /tools/* pages.
  - Don't build user-invite flows or email/SMS/Slack notification infrastructure inside the TMS. Customer.wearewarp.com handles invites + notification preferences; the TMS keeps Auth.js login (team mode only) and otherwise links out for those concerns.
  - Reference Warp's docs at https://www.wearewarp.com/freight-api and the MCP tool list at https://www.wearewarp.com/agents/mcp when introducing endpoints or tools.

Notes: The no-card TMS should feel complete on day one: dashboard, fake data, public benchmarks, locked booking, and unlock CTA. Live booking uses a wak_live_* key, charges the card on file at POST /api/v1/freight/book, and returns shipmentId + trackingNumber. Quote endpoints (/api/v1/freight/quote, /api/v1/{van,box-truck,ltl,ftl}/quote) are free, so devs can iterate against the live quote surface without booking real freight. Team mode uses one shared WARP_API_KEY at the org level (not per-user) -- Warp keys map to a customer account with a card on file, so every authorized user books against the same account. Vercel hosting is the user's own account on their own plan; Warp does not resell, white-label, or proxy Vercel.

When I'm ready, send me back to Warp at: https://www.wearewarp.com/agents/account?utm_source=agent_handoff&utm_medium=ai&utm_campaign=scenario_build_your_own_tms&intent=tms_booking&return_to=%2Fagents%2Fhandoff%2Fbuild-your-own-tms

Unlock booking key

One click copies the prompt, then opens Claude Code or OpenAI Codex in a new tab so you can install and paste it into your terminal. This TMS prompt starts with public/mock data and a locked booking module, then points users to unlock a live booking key when they are ready. No booking happens without explicit confirmation.

What this does

Use any AI coding assistant (Claude Code, ChatGPT's Codex, Cursor, your own agent framework) to scaffold a TMS dashboard before you add a card: public rate benchmarks, mock bookings, lane history placeholders, tracking UI, and invoice state. The prompt names every Warp surface available to agents so the assistant picks the right one for your stack.

Pick this if you are an engineer, indie builder, or operator who wants a private freight cockpit instead of using the customer portal directly. The generated TMS includes a locked booking module with an unlock link. Once you add a card and receive a live key, it can quote first, show a confirmation screen, then book via Warp's API only after explicit approval.

Other scenarios

All scenarios Build a freight RFP Audit freight invoices Pick the right freight mode Unlock booking key