Request Status Values

The request_status field provides a simplified view of where a service request stands in relation to your integration. This is separate from the internal VectorCare state (request_current_state).

For many integrations, request_status is all you need to drive your workflow. The action field is available for integrations that need more granular detail about what triggered the webhook.

Status Values

Status	Description
AVAILABLE	Request exists but is not yet officially assigned to your organization
ASSIGNED	Request is officially assigned to you and you have responsibility for it
COMPLETED	Request has been fulfilled according to service criteria
UNAVAILABLE	Request is no longer accessible (canceled, withdrawn, or inactive)

Status Details

AVAILABLE

The request has been broadcast to your organization but you haven’t accepted it yet.

What to do:

• You may want to wait before creating the trip in your system
• Use the Accept endpoint to claim the request
• Or use the Decline endpoint to pass on it

Note

In many cases, you might not want requests in your system until they reach ASSIGNED status.

ASSIGNED

The request is officially yours to fulfill. This happens when:

• You accepted a broadcast
• The requester directly assigned the trip to you
• Your proposal was accepted

What to do:

• Create the trip in your system
• Begin dispatching/scheduling
• Send state updates as the trip progresses

COMPLETED

The trip has been marked complete in VectorCare. The service was delivered according to the defined criteria.

What to do:

• Update your records to reflect completion
• No further state updates needed

UNAVAILABLE

The request is no longer accessible to your organization. This can happen when:

• The request was canceled by the requester (all providers receive UNAVAILABLE)
• Another provider accepted the broadcast (you receive UNAVAILABLE)
• The broadcast expired without a response
• The request was reassigned to another provider

What to do:

• Remove or cancel the trip in your system
• Note: The data field will be null in this case

Note

When a request is canceled, all providers who received the broadcast will receive an UNAVAILABLE webhook. Similarly, when one provider accepts a broadcast, all other providers will receive UNAVAILABLE.

Example UNAVAILABLE payload:

{
  "event_id": "xyz789abcdef",
  "event_timestamp": "2025-05-09T02:30:00Z",
  "service_request_id": "KP-ABCD1234",
  "request_status": "UNAVAILABLE",
  "action": "BROADCAST_CANCELED",
  "data": null
}

Example Payloads

AVAILABLE Request

{
  "event_id": "abc123",
  "service_request_id": "KP-ABCD1234",
  "request_status": "AVAILABLE",
  "action": "BROADCAST_RECEIVED",
  "data": {
    "patient_first_name": "John",
    "patient_last_name": "Doe",
    // ... full data object
  }
}

UNAVAILABLE Request

{
  "event_id": "xyz789",
  "service_request_id": "KP-ABCD1234",
  "request_status": "UNAVAILABLE",
  "action": "BROADCAST_CANCELED",
  "data": null
}

Status vs. Action

The request_status tells you the current state of the request relative to your organization.

The action tells you what happened to trigger this webhook.

For example:

• request_status: ASSIGNED + action: BROADCAST_ACCEPTED = You just accepted the request
• request_status: ASSIGNED + action: REQUEST_DATA_UPDATED = The request data changed (still assigned to you)

See Actions for the full list of action values.