Connect TMS load updates to Lane

Lane can receive load updates through an inbound webhook: your TMS or middleware sends an HTTP request, and Lane stores the load snapshot for use in your workspace. Your administrator maps the supported fields and configures when updates are sent.

This is an inbound connection. Lane does not install a native vendor adapter, query your entire TMS, or write changes back. The workspace can use received context to help summarize a load, draft an email, or prepare a check-call; it does not make that call or send that email.

Before you start

You need a Lane workspace and a TMS, middleware service, or integration process that can:

• Send an HTTPS POST request with a JSON body.
• Set an Authorization header.
• Map a stable load ID and the supported load fields.
• Supply a unique event ID for each change and a source update timestamp with a time zone.

A TMS administrator or integration partner can check those requirements. A vendor name alone is not proof of compatibility. If your system cannot create this request directly, your administrator may need middleware to map and send it.

Sign in to your workspace, then open the TMS connection view.

1. Prepare the connection in Lane

Enter your TMS name and choose Create connection. Lane displays a private endpoint and an authorization key for your workspace.

Creating these details prepares the connection. It does not mean that a load update has arrived. The view initially shows Waiting for the first event.

Store the key in your sending system’s protected connection configuration. Do not put it in a load field, shared screenshot, or chat message. If you no longer have the key, the workspace lets you rotate it. Update the sending system when you do: the replacement key supersedes the old one.

2. Configure the HTTP request

Copy the exact endpoint from your workspace. Its format is:

POST https://www.keelway.com/api/lane/tms/YOUR_CONNECTION_ID
Content-Type: application/json
Authorization: Bearer YOUR_CONNECTION_KEY

YOUR_CONNECTION_ID and YOUR_CONNECTION_KEY are placeholders, not working credentials. Keep the endpoint and key from the same workspace connection together.

3. Map the supported JSON fields

This is an illustrative dry-van load update. Replace its identifiers, route, status, and timestamps with the source record you intend to send.

{
  "event_id": "dv-2048-update-001",
  "load": {
    "load_id": "DV-2048",
    "origin": "Ontario, CA",
    "destination": "Atlanta, GA",
    "equipment": "53-foot dry van",
    "status": "in_transit",
    "eta": "2026-09-25T08:30:00-04:00",
    "updated_at": "2026-09-23T09:00:00-04:00"
  }
}

Use timestamps such as 2026-09-23T09:00:00-04:00 or the UTC equivalent with Z. Do not send a date-only value or a local time without a zone. The endpoint rejects source update times more than one hour in the future.

The request schema is strict. Extra fields at the top level or inside load are rejected. Driver phone numbers, appointment windows, rates, documents, and arbitrary notes are not fields in this version of the connection. If your source sends a larger event, map it down to the supported object.

4. Send a test update

Use your sending system’s test action, or have your administrator run a request from an appropriate environment. This example assumes the endpoint and key have already been configured as environment variables and the JSON is saved as lane-load-update.json:

curl --request POST "$LANE_WEBHOOK_URL" \
  --header 'Content-Type: application/json' \
  --header "Authorization: Bearer $LANE_CONNECTION_KEY" \
  --data-binary @lane-load-update.json

A newly accepted event returns:

{"ok":true,"result":"accepted"}

Refresh the connection view in Lane. It should show Updates received and a last-event time after a newly accepted event. Confirm that the load ID and received values are the ones you intended to send.

Event IDs, retries, and out-of-order updates

Use a new event_id for a new change. If a request must be retried, send the same event ID and payload again. A previously recorded event ID returns:

{"ok":true,"result":"duplicate"}

That response means the repeated event is ignored. Changing the payload while keeping the old event ID will not create a new load update.

Lane compares a new event’s updated_at with the stored source timestamp for the same load. An older source update does not overwrite a newer stored snapshot. An equal or newer source timestamp can update it. An accepted event is therefore not, by itself, proof that the stored load fields changed: a unique but older event can be accepted while the newer snapshot remains in place.

Troubleshooting the first event

Use the received context with the right expectations

A useful first request in Lane is:

Summarize the latest received information for DV-2048. State the source update time, identify anything we still need to confirm, and draft a short customer update for review.

Lane’s chat receives context from up to 20 recent load snapshots. It cannot make a live query for an arbitrary record elsewhere in your TMS. If it does not have the load, check what your connection sent and what was received before relying on an answer.

The source timestamp matters even when the connection says Updates received. A received snapshot is not a continuous tracking feed, and Lane cannot independently confirm a driver’s present location or a new ETA.

What to connect next

Begin with one representative load and inspect its subsequent updates before expanding the feed. Save your team’s time zone, preferred draft length, and working context in Lane’s instructions.

For the broader product boundary, read what a broker AI agent can do. For the architecture decision, see how TMS, BMS, and AI tools fit together. Open your Lane workspace when you are ready to configure the connection.