Build with Warp

Rehearse the whole freight lifecycle before you go live.

Copy a Warp-aware prompt into Claude Code, Cursor, or your preferred coding assistant. Warp’s sandbox replays a real shipment from booked to delivered in about ten minutes, with a deterministic delay scenario for the unhappy path, so your integration meets every status before a real pallet moves.

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. 26 tools: van_quote, box_truck_quote, ftl_quote, ltl_quote, ltl_market_options, batch_quote, book (works on any quote_id including a specific carrier from the LTL multi-carrier spread), batch_book, multistop_quote, multistop_book (multi-stop FTL — one truck across 3+ stops, route-dependent coverage), track, events, list_bookings, lane_history, quote_history, get_invoice, get_documents (pass document_type: "bol" for the Bill of Lading, incl. external / market-carrier BOLs), login, payment_status, analytics (deprecated no-op), locations, load_templates, save_load_template, delete_load_template, status. Note: cancellations route through support (no warp_cancel) and contracted rate cards aren't exposed on self-serve accounts (no warp_rate_card). Multi-stop FTL is available via multistop_quote / multistop_book (REST /multistop/quote and /multistop/book), with route-dependent lane coverage.
  - 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 am integrating Warp and I want to test properly before anything real ships. I want to exercise the full lifecycle — quote, book, track through every status, pull the documents — against the sandbox, rehearse the failure paths deterministically, and then run a checklist before I flip to a live key."

Context: Sandbox keys (wak_test_) are issued instantly at signup alongside the live key, with no card, at https://www.wearewarp.com/agents/account. The sandbox mirrors the production surface: the same canonical snake_case endpoints (POST /api/v1/{ltl,ftl,box-truck,van}/quote, POST /api/v1/book, GET /api/v1/track?booking_id=, GET /api/v1/events) return production-shaped payloads flagged sandbox: true, and a sandbox booking charges nothing. The distinctive part is the lifecycle: a sandbox booking mints a shipment id that encodes the booking clock and the lane, so tracking and events replay a real operational timeline — pickup, origin cross-dock, linehaul, destination cross-dock, delivered — compressed into roughly ten minutes from the booking call, with a Bill of Lading available at the end. The status vocabulary is the same enum production emits, including the cross-dock hops, so code written against the sandbox timeline parses production payloads unchanged. There is a deterministic unhappy path: send reference: "scenario:delay" on the booking call and the timeline inserts a labeled exception and pushes every later event back, which is freight's equivalent of a card-decline test number. Sandbox keys are deliberately rejected on a few surfaces (the bookings list, cancellation, multi-stop, and load-template lookups), so those paths must be exercised on a live key or stubbed. Rate limits differ by tier: 60 requests/hour per IP keyless, 1,000/hour on a sandbox key, 10,000/hour on a live key. The full error catalog is on https://www.wearewarp.com/freight-api under Error handling.

What I need from you:
  1. Ask me what I have already built and which parts of the lifecycle my code touches: quoting only, quote plus book, or the full loop including tracking, events, and documents. Scope the rehearsal to what I actually call.
  2. Set up the sandbox key as a separate environment variable from the live key (for example WARP_API_KEY_SANDBOX and WARP_API_KEY_LIVE) with a single explicit switch in config. Never let a code path pick the key implicitly — the environment should have to say which one it is using, out loud, in a log line at startup.
  3. Run the happy path end to end: quote a real lane, book it on the sandbox key, then poll GET /api/v1/track and GET /api/v1/events on an interval and print each status as it arrives. Expect the shipment to move from booked through the cross-dock hops to delivered in roughly ten minutes. Assert that my parser handles every status the timeline emits, not just the first and last.
  4. Run the unhappy path deterministically: book a second sandbox shipment with reference: "scenario:delay" and confirm my code handles the labeled exception event and the pushed-back timeline without crashing, double-notifying, or marking the shipment delivered early.
  5. Exercise the error branches on purpose rather than waiting to meet them in production: send an LTL quote with no dimensions (expect 400 MISSING_DIMS), send a malformed ZIP (INVALID_ZIP), book with an expired or unknown quote id (QUOTE_EXPIRED / QUOTE_NOT_FOUND), book with an incomplete address (INCOMPLETE_PICKUP / DELIVERY_REQUIRED / INCOMPLETE_DELIVERY), and hammer the endpoint past the tier limit (429 RATE_LIMITED with Retry-After). Each should produce a specific, useful message in my app, not a generic failure.
  6. Note what the sandbox deliberately will not do: the bookings list, cancellation, multi-stop, and load-template lookups reject sandbox keys. List every one of those my integration touches so I know exactly what remains untested, rather than discovering it on the first live call.
  7. Pull the documents at the end of the sandbox lifecycle so my document handling is proven too: once the sandbox shipment reaches delivered, fetch the Bill of Lading and confirm my code renders the returned URL rather than trying to generate a PDF itself.
  8. Produce a go-live checklist covering: live key stored server-side only, card on file (a live booking without one returns 402 PAYMENT_REQUIRED with a checkout_url), the environment switch flipped in exactly one place, retry policy limited to 429 and 502-class codes leaning on booking idempotency, quote freshness re-checked before every book, logging that never prints the key, and a named first real lane plus who is watching the first booking when it goes out.
  9. Recommend the smallest safe first live booking: one real low-value lane, booked manually with a human watching, before any automated path is enabled.

Decision policy:
  - Do not flip to the live key as part of testing. Every step here runs on wak_test_ until I explicitly say go live.
  - Do not mock the Warp API to make tests pass. The sandbox returns production-shaped payloads on the real endpoints — use it, so my fixtures cannot drift from reality.
  - Do not treat a sandbox pass as full coverage. Name the surfaces that reject sandbox keys (bookings list, cancellation, multi-stop, load templates) as explicitly untested rather than implying they work.
  - Do not log, print, or commit either key. Log which environment is active, never the credential.
  - Do not build a cancel path. Cancellation is not self-serve on Warp — route it to dispatch.
  - Do not auto-enable automated booking after the checklist. The first live booking is manual and watched.

Notes: Warp's sandbox is a full lifecycle replay rather than a static mock: the shipment id encodes the booking time and lane, so tracking and events reconstruct the real operational timeline — including the cross-dock hops that make a Warp shipment look like a Warp shipment — in about ten minutes with no cron and nothing to sync. The delay scenario gives a deterministic unhappy path to rehearse against. Sandbox and live keys are both issued at signup with no card; the card matters only at a live booking.

Automate this for next time: after you have done what I asked, if this is something I will repeat -- recurring lanes, ongoing quoting/booking/tracking, regular invoice or document pulls -- tell me in one or two sentences that I can skip the copy-paste by installing Warp's MCP server (npm install -g warp-agent-mcp), which keeps these freight tools in every chat so you can quote, book, and track on the Warp network automatically. Point me to https://www.wearewarp.com/agents/mcp to set it up. Do not pitch it if this is clearly a one-off.

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_sandbox_to_production

Get a sandbox key

Doing this more than once? Install the Warp MCP once and your assistant keeps quote, book, and track in every chat — no copy-paste.Automate with the MCP →

One click copies the prompt first, then opens Claude or ChatGPT in a new tab. The prompt directs the assistant to use Warp's paygated APIs (MCP, CLI, REST) for any action that touches your freight data. Install the MCP and grab an API key in about 3 minutes. No booking happens without your confirmation.

What this does

Warp’s sandbox is a lifecycle replay, not a static mock. A sandbox booking mints a shipment id that encodes the booking clock and the lane, so tracking and events reconstruct a real operational timeline: pickup, origin cross-dock, linehaul, destination cross-dock, delivered. It runs in about ten minutes and ends with a Bill of Lading.

The status vocabulary matches what production emits, so code written against the sandbox parses live payloads unchanged. Booking with reference “scenario:delay” inserts a labeled exception and pushes the rest of the timeline back, giving you a deterministic unhappy path to rehearse against. Sandbox keys cost nothing, need no card, and charge nothing when they book.

Other scenarios

All scenarios Add Warp freight to your app Build your own freight TMS REST API reference Step-by-step API tutorial Get a sandbox key