Build with Warp

Put pallet shipping inside your marketplace checkout.

For a founder or engineer whose marketplace sells physical goods that move on pallets. Copy this prompt into Claude Code, Cursor, or any coding assistant and it builds the whole path: a delivered price on the listing, a locked quote at checkout, one booking per seller when the order confirms, and live tracking on the order page. Quotes are free and keyless. A key is only needed to book.

AI prompt to add freight shipping to a marketplace checkout

Copy the prompt below into Claude Code, Cursor, or any coding assistant. It builds a typed Warp client and wires a delivered price on the listing, a locked quote at checkout, one booking per seller when the order confirms, and tracking on the order page. Quotes are keyless and free; a key is only needed to book.

How does a marketplace price pallet shipping before the sale

Call POST /api/v1/quote with the seller ZIP, buyer ZIP, pallets, weight and dimensions. It returns every mode Warp can run on that lane, cheapest first, with a quote_id that holds for 72 hours. Show the cheapest available row as the delivered price and re-quote at checkout if it is close to expiry.

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. 31 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 run a marketplace where buyers purchase physical goods from sellers and those goods ship on pallets (LTL freight, sometimes a box truck or cargo van locally). Today shipping is quoted by hand or after the sale. I want freight priced inside my product: the buyer sees a delivered price while they shop, the price is locked when they check out, the shipment is booked automatically when the order confirms, and the buyer and seller can watch it move on the order page. I want a small, typed module in my existing codebase, not a new dashboard, and I want it working against a sandbox before it ever touches a real card."

Context: Warp's REST API is documented at https://www.wearewarp.com/freight-api with the machine-readable spec at https://www.wearewarp.com/.well-known/openapi.json. Requests are snake_case under /api/v1. QUOTING IS KEYLESS: POST /api/v1/quote takes one body ({origin_zip, destination_zip, pickup_date as YYYY-MM-DD, pallets, weight_lbs_per_pallet, commodity, length_in, width_in, height_in}) and returns results[] for all four modes (ltl, cargo_van, box_truck, ftl) sorted cheapest bookable first, each row carrying available, quote_id, price_usd, transit_days and expires_at, or available:false with a reason when the lane has no coverage on that mode. The single-mode endpoints POST /api/v1/ltl/quote, /van/quote, /box-truck/quote and /ftl/quote return the same shape for one mode. Keyless calls are limited to 60 per hour per IP; a free wak_test_ sandbox key raises that to 1,000 and a wak_live_ key to 10,000. Over the limit returns 429 RATE_LIMITED with Retry-After. LTL REQUIRES length_in, width_in and height_in or it returns 400 MISSING_DIMS, which is the most common first-integration failure. Quotes hold for 72 hours via expires_at. BOOKING IS BEARER-AUTHED: POST /api/v1/book with the quote_id, plus pickup and delivery objects that each need street, city, state, zipCode, contactName, phone and email (missing fields return INCOMPLETE_PICKUP, DELIVERY_REQUIRED or INCOMPLETE_DELIVERY). pickup_window and delivery_window are {from, to} pairs of HH:MM strings. Bookings are IDEMPOTENT on quote_id: a retried /book returns the original confirmation and never double-charges, and a concurrent duplicate returns 409 BOOKING_IN_PROGRESS, which means wait and retry. A live booking with no card on file returns 402 PAYMENT_REQUIRED with a checkout_url in the body. On a 502-class failure after a charge, /book auto-refunds and returns refunded plus payment_intent. Tracking is GET /api/v1/track?booking_id={id} and returns the status, events and windows for that shipment; poll it, there is no push feed to build against. Both wak_test_ and wak_live_ keys are issued instantly at https://www.wearewarp.com/agents/account with no card; a wak_test_ key returns production-shaped payloads marked sandbox:true and never charges, so integration tests run against the real response shape. Spending limits (a cap per booking and a confirm-over threshold) are set by the account owner in the dashboard and readable at GET /api/v1/agents/spend-policy; the agent cannot change them. Cancellation is NOT self-serve (410 CANCEL_NOT_SELF_SERVE): route cancellations to dispatch. Warp does not ship hazmat on any mode and does not ship flatbed, step-deck, conestoga or oversize; reefer and white-glove are supported. The full error catalog is on /freight-api under Error handling.

What I need from you:
  1. Ask me four things before writing code: (a) language and framework, (b) where seller pickup addresses and pallet dimensions live in my data model today, (c) whether a cart can contain goods from more than one seller, and (d) whether I want booking now or quoting only behind a feature flag for this pass. If I am unsure on (d), build quoting first and booking behind a flag.
  2. Generate a typed Warp client from https://www.wearewarp.com/.well-known/openapi.json. Do not hand-guess field names. Keep it dependency-free beyond my existing HTTP client, and read the key from a server-side environment variable only. Quotes may be proxied through my own backend route so a listing page can show a price without any Warp credential reaching the browser.
  3. Listing and cart: price the delivered cost keylessly with POST /api/v1/quote using the seller warehouse ZIP as origin_zip, the buyer ZIP as destination_zip, the listing pallet count, weight and dimensions, and the next business day as pickup_date. Show the cheapest available row as the delivered price and keep the quote_id and expires_at on the cart line. If every row comes back available:false, show the reason and fall back to a request-a-quote path rather than hiding freight.
  4. Multi-seller carts: freight is one shipment per seller, so build one quote and later one booking per seller group in the cart. Sum the delivered prices for the buyer, but never merge two sellers into one booking.
  5. Checkout: re-check freshness before the buyer pays. If the stored quote is within two minutes of expires_at or past it, re-quote the same lane, show the new price, and only then take payment. Never carry a stale quote_id into the order.
  6. Order confirmation, server side: POST /api/v1/book once per seller group with that group quote_id, pickup built from the seller record and delivery from the buyer record, all seven address fields present. Store booking_id, price_usd and the raw confirmation on the order. Because /book is idempotent on quote_id, a retried call after a timeout is safe and returns the same confirmation; treat 409 BOOKING_IN_PROGRESS as wait and retry, not as an error.
  7. Order page: poll GET /api/v1/track?booking_id={id} on a sensible interval and render status, events and windows for both buyer and seller. Cache the last response and show it while a poll is in flight.
  8. Handle the error catalog explicitly, keyed on the code field never the message: MISSING_DIMS, INVALID_ZIP, MISSING_PICKUP_DATE, QUOTE_EXPIRED and QUOTE_NOT_FOUND (re-quote and use the fresh id), PAYMENT_REQUIRED (surface the checkout_url to the account owner, do not swallow it), INCOMPLETE_PICKUP, DELIVERY_REQUIRED and INCOMPLETE_DELIVERY (name the missing field), RATE_LIMITED (respect Retry-After), and the 502-class UPSTREAM_ERROR, BOOKING_FAILED and BOOKING_CRASH. Retry with backoff and jitter on 429 and 502-class codes only, never on a 400.
  9. Tests: run the whole lifecycle against a wak_test_ sandbox key, not against a fake server. Quote a lane, book it, poll it to delivered. Fixtures come from real responses so the shapes stay honest.
  10. Finish with a go-live checklist I can paste into the pull request: swap wak_test_ for wak_live_, add a card in the dashboard, set the per-booking cap and confirm-over threshold there, confirm the key is server-side only, and list what is deliberately out of scope (cancellation, hazmat, flatbed).

Decision policy:
  - Do not invent endpoints or field names. Read https://www.wearewarp.com/.well-known/openapi.json and use what is there; if something I asked for is not in the spec, say so instead of inventing it.
  - Do not put the API key in browser code, in the repo, or in a query string. Server-side environment variables only.
  - Do not book anything during development against a live key. Use the sandbox key until I explicitly say to go live.
  - Do not merge two sellers into one booking. One quote and one booking per seller group, always.
  - Do not build a cancel button. Cancellation is not self-serve on Warp; route it to dispatch.
  - Do not offer hazmat, flatbed, step-deck, conestoga or oversize. Reefer and white-glove are valid.
  - Do not write a blanket retry wrapper. Retry only 429 and 502-class failures, and rely on booking idempotency on quote_id rather than inventing your own idempotency keys.
  - Do not skip LTL dimensions. Put length_in, width_in and height_in in the type so the compiler catches a missing one, not the API.

Notes: This is the marketplace path, distinct from adding a quote button to an internal tool: freight becomes a line in the transaction, priced while the buyer shops and booked when the order confirms. Quoting is keyless and free, so the listing price works before anyone signs up. A key is needed only to book, both keys are issued instantly at signup with no card, and the card is required only at the moment of 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_marketplace_checkout

Get your API keys

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

Use a coding assistant to put pallet freight inside a marketplace that sells physical goods. The prompt asks where seller addresses and pallet dimensions live in your data model, then builds the path end to end: a delivered price on the listing from the keyless quote endpoint, a freshness check at checkout, one booking per seller when the order confirms, and tracking on the order page.

Pick this when freight is a line in your transaction rather than a button in an admin tool. Everything runs against a sandbox key first, which returns production-shaped responses and never charges. Booking on the live key needs a card on file, and the spending caps are set by the account owner in the dashboard, not by the code.

Other scenarios

All scenarios Add freight to an app you already have Rehearse it in sandbox, then go live Build your own freight TMS Get your API keys