Webhook Actions

The action field indicates what event triggered the webhook. This helps you understand why you received the notification and what changed.

Many integrations can rely solely on request_status to drive their logic (e.g., create a trip when AVAILABLE, update when ASSIGNED, remove when UNAVAILABLE). The action field provides additional context for integrations that need to handle specific events differently, but it is not required for most workflows.

Action Values

Broadcast Actions

Action	Description
`BROADCAST_RECEIVED`	A new broadcast was sent inviting you to accept the request
`BROADCAST_ACCEPTED`	You successfully accepted the broadcast and are now assigned
`BROADCAST_DECLINED`	You declined the broadcast - request no longer available to you
`BROADCAST_CANCELED`	The broadcast was canceled by the requester before you responded
`BROADCAST_EXPIRED`	The broadcast expired without a response from you

Proposal Actions

Action	Description
`PROPOSAL_SUBMITTED`	You submitted a proposal - awaiting requester review
`PROPOSAL_ACCEPTED`	Your proposal was accepted - you are now assigned
`PROPOSAL_DECLINED`	Your proposal was declined by the requester

Change Request Actions

Action	Description
`CHANGE_REQUEST_ACCEPTED`	Your change request was approved - agreed time updated to your proposed time
`CHANGE_REQUEST_DECLINED`	Your change request was declined - original agreed time remains

Data Actions

Action	Description
`REQUEST_DATA_UPDATED`	Request data was modified (times, locations, patient info, etc.)

Action by Status

Here’s how actions typically map to request status:

Action	Typical request_status
`BROADCAST_RECEIVED`	`AVAILABLE`
`BROADCAST_ACCEPTED`	`ASSIGNED`
`BROADCAST_DECLINED`	`UNAVAILABLE`
`BROADCAST_CANCELED`	`UNAVAILABLE`
`BROADCAST_EXPIRED`	`UNAVAILABLE`
`PROPOSAL_SUBMITTED`	`AVAILABLE`
`PROPOSAL_ACCEPTED`	`ASSIGNED`
`PROPOSAL_DECLINED`	`UNAVAILABLE`
`CHANGE_REQUEST_ACCEPTED`	`ASSIGNED`
`CHANGE_REQUEST_DECLINED`	`ASSIGNED`
`REQUEST_DATA_UPDATED`	Varies (usually `ASSIGNED` or `AVAILABLE`)

Common Scenarios

New Trip Available

{
  "action": "BROADCAST_RECEIVED",
  "request_status": "AVAILABLE",
  "service_request_id": "KP-ABCD1234"
}

A new request was broadcast to you. Review and decide whether to accept or decline.

Trip Assigned to You

{
  "action": "BROADCAST_ACCEPTED",
  "request_status": "ASSIGNED",
  "service_request_id": "KP-ABCD1234"
}

You accepted the broadcast (or the requester assigned it directly). Create the trip in your system.

Trip Details Changed

{
  "action": "REQUEST_DATA_UPDATED",
  "request_status": "ASSIGNED",
  "service_request_id": "KP-ABCD1234"
}

Something changed on a trip you’re assigned to. Compare the data object with your records and update accordingly. Common changes include:

Pickup/appointment times
Addresses
Patient information
Special requirements

Trip No Longer Available

{
  "action": "BROADCAST_CANCELED",
  "request_status": "UNAVAILABLE",
  "service_request_id": "KP-ABCD1234"
}

The request was canceled or withdrawn. Remove it from your pending queue.

Handling `REQUEST_DATA_UPDATED`

The REQUEST_DATA_UPDATED action is the most common webhook you’ll receive. It fires whenever any field on the request changes.

Any field can change after a request is assigned, including pickup times, locations, and patient information. The only fields guaranteed to remain constant are the identifiers (service_request_id, organization_id, etc.).

Best practice: Replace your stored data entirely with the new payload rather than comparing field-by-field. The data object always contains the complete current state of the request.