Skip to main content
New routes, fields and behaviour, newest first. See Versioning for what can change inside /v1.
​
List and manage your loads
  • Brokers list the loads their brokerage posted through the API: GET /v1/loads (MCP: list_loads), newest first, a page at a time.
  • Broker setup changes show on the very next read of GET /v1/broker/setup.
  • Step-by-step setup for Claude, ChatGPT, Claude Code and Cursor: add the MCP URL and sign in.
  • Sign-in accepts the offline_access scope, and the page offers a new code after a minute.
  • list_loads answers states as codes (TX) and dates as YYYY-MM-DD, and refuses limit: 0 over MCP too.
  • post_load reads numbers wrapped in extra quotes and refuses a value that isn’t a number instead of dropping it.
  • A list cursor only works with the status it came from.
  • Manage a load: edit (PATCH /v1/loads/{id}), pause, resume, reopen after a carrier falls off, and delete, as the dashboard can. New error invalid_state.
  • GET /v1/loads/{id} shows what was posted (load); POST /v1/loads takes your own reference_number.
  • GET /v1/loads shows each load’s waiting offers; needs_decision=true lists only loads with offers waiting.
  • agreed_rate shows the accepted offer’s rate; offer and outreach times are RFC 3339.
  • Carrier loads show state codes (TX); trucks and lanes take only real state or province codes and trim cities.
  • A truck Idempotency-Key reused for a different truck answers 422 idempotency_key_reused.
  • Every carrier error has a next_step; schema errors read plainly (“limit must be at least 1”).
​
agent.lanesurf.com
​
Search near a ZIP or city
  • Carriers search loads near a ZIP code (origin_zip) or a city: the same ZIP first, then within 50, 100 and 150 miles, then the rest of the state. Each load has deadhead_miles and match.
​
Bids and brokerages
  • A declined bid can be sent again: a new rate reopens it for the broker. Only an accepted bid is final.
  • Brokerages choose whether carriers’ AI agents see their loads (loads_visible_to_carriers in PATCH /v1/broker/setup).
  • Broker reps are emailed when a carrier’s agent bids on their load and when they accept an offer.
  • Signing in from an AI app with a password or an API key asks for a code sent by email.
​
Outreach history and Google sign-in
  • Outreach history: GET /v1/loads/{id}/outreach for brokers and GET /v1/carrier/outreach for carriers.
  • Lanesurf customers can sign in from an AI app with their dashboard account or with Google.
  • Posted trucks and saved lanes get verified carriers pitched matching loads.
  • Carriers under review can be verified by Lanesurf’s team.
​
Safe retries and request IDs
  • POST /v1/loads requires an Idempotency-Key, so a retry never creates a second load.
  • Accepting an offer takes the rate the person agreed to, and answers 409 offer_changed if the carrier changed it.
  • Every response has an X-Request-Id header, and every error a request_id.
​
Self-serve signup and MCP
  • Carriers and brokerages get a key themselves with POST /v1/signup: a work email, an MC or DOT number and an 8-digit code.
  • Signup answers and load errors include next_step, telling an agent what to do next.
  • The MCP server: one tool per route, with the same keys, limits and error codes.
​
Stalled loads and updated bids
  • New load status stalled, with status_reason, for a load that no carrier has been contacted about.
  • Bidding on the same load again updates the bid instead of making a second one.
​
First release
  • First release: broker loads, carrier signup, trucks, lanes, load search and bids, with the OpenAPI 3.1 contract.