Webhooks Setup

Outbound webhooks are POST requests Augment sends to URLs you configure when an event occurs in a workflow you're integrated with. Your TMS owns the host, path, and authentication for each endpoint; Augment owns the event payload.

Which version should I use?

v2 delivers every event inside the shared envelope (id, workflow, occurredAt, loadNumber, customerLoadInternalId, eventType, data), including Capacity Sourcing and Load Building events (BID_CREATED, LOAD_DRAFT, UPLOAD_DOCUMENT). In v1, those three are delivered as flat payloads. The domain fields are the same across versions — only the wrapping differs.

Track & Trace events were also redesigned in v2.

New integrations should use v2. Even if you're starting with Capacity Sourcing or Load Building today, picking v2 up front avoids re-implementing listeners if you add Track & Trace in a later wave. v1 remains supported for existing integrations — no migration is required if you are already live on v1.

See the full v1 → v2 event mapping at the top of the Webhooks reference.

What you provide to Augment

During setup, hand the following to your Augment CS contact:

1. Endpoint URL(s) — one or more URLs that will receive webhook POSTs.
2. Event routing — which events each endpoint should receive (you may use a single endpoint for all events and route internally by eventType).
3. Authentication method — Augment supports multiple auth types (Basic, Bearer token, custom header). Specify which to use per endpoint.

Your listener must return a 200 status code to acknowledge receipt.

Self-service webhook management

Access is gated. Please request access from your Augment contact if you want to self-manage webhook endpoints or webhook event subscriptions.

After access is enabled, you can use the endpoints documented in the Webhook Endpoints and Webhook Event Subscriptions sections of the Augment API Reference.

Webhook endpoints define the HTTPS listeners where Augment sends event payloads. Use them to create and manage the destination URL, outbound delivery authentication, custom headers, and display name for each listener. Self-service endpoints support version 2 webhook delivery only.

Webhook event subscriptions connect an endpoint to the event types you want to receive at that endpoint. A single endpoint can receive multiple event types by creating one subscription per event type.

Recommended sequence:

1. Create the delivery endpoint with POST /v2/webhook-endpoints. This is the listener that will receive webhook event payloads. Save the returned endpoint id.
2. List supported event types with GET /v2/webhook-event-types.
3. Create a subscription with POST /v2/webhook-subscriptions. Use the endpoint id as webhookEndpointId and choose one supported eventType.
4. Send a test delivery with POST /v2/webhook-subscriptions/{subscriptionId}/test. The test uses the subscription and endpoint configuration you created, so you can verify that the endpoint URL, auth, custom headers, and listener behavior are working.

To update a webhook endpoint later, call PATCH /v2/webhook-endpoints/{webhookEndpointId} with the new url, auth, customHeaders, or name. Existing subscriptions stay attached to the same endpoint ID, so you do not need to recreate subscriptions unless you want to route an event type to a different endpoint. After changing endpoint URL or auth, test each affected subscription to confirm deliveries still succeed.

Webhook endpoint authentication is outbound delivery auth. Today, self-service endpoints support bearer-token delivery auth, where Augment sends Authorization: Bearer <token> to your listener. This is separate from the API key authentication your system uses to call Augment.

Required and optional events per workflow

Workflows are listed in load lifecycle order. v2 names shown first; v1 names in parentheses.

Load Building

Capacity Sourcing

Appointment Scheduling

Track & Trace

Carrier Support

Purchase Order Management (v2 only)

What Augment learned from a supplier about a purchase order, sent back so your system can apply it. Today that is new expected dates for a purchase order and its lines — one event per update, scoped to the purchase order, with the affected lines nested.

These events are about a purchase order rather than a load, so they are the one kind that does not use the shared envelope: the payload arrives flat, with no id, workflow, loadNumber, or eventType wrapped around it. Point them at their own endpoint — there is no eventType to route on.

Ask your Augment contact to set up a subscription to these events.

Agent Activity (v2 only)

These events report what an Augment agent did on a load — who it talked to, and how the work progressed. All are optional, and all are v2-only.

Unlike the tables above, these are not scoped to a single workflow: any agent can emit them, so read workflow on the envelope to see which one did.

Ask your Augment contact to set up a subscription to these events.

Event envelope (v2 only)

Every v2 event about a load shares this envelope, so a single listener can route by eventType. workflow is the originating Augment workflow, or null for Capacity Sourcing and Load Building events:

{
  "id": "evt_01H...",
  "workflow": "TRACK_AND_TRACE",
  "occurredAt": "2026-05-13T12:34:56Z",
  "loadNumber": "LOAD-456",
  "customerLoadInternalId": "INT-789",
  "eventType": "TRACKING_UPDATE",
  "data": { /* event-specific fields */ }
}

In v2, UPLOAD_DOCUMENT, BID_CREATED, and LOAD_DRAFT are wrapped in this same envelope (with workflow: null). On v1 endpoints those three are delivered as flat payloads instead.

PURCHASE_ORDER_UPDATE is not wrapped in the envelope at all. It is about a purchase order, not a load, so the envelope's load references would have nothing to hold — the payload is sent flat.

Testing

Work with your Augment CS contact to send test webhooks and verify your endpoints receive and process them correctly. Design your handlers to be idempotent — Augment retries failed deliveries with exponential backoff, which may result in the same event being delivered more than once.

Questions?

Reach out to your CS contact for help setting up or testing your webhook subscriptions.