Skip to main content
Webhooks let your system react to events as they happen, like a document being filed, a case moving to a new phase, or a case being closed. Instead of polling the API, you register a URL and we send you a POST request whenever something important occurs.

​
How it works

  1. Register a URL in your organization’s developer settings.
  2. Events fire as your cases progress through the arbitration process.
  3. We send a POST request to your URL with a JSON payload describing what happened.
Every webhook is delivered via a POST request with a JSON body and the header x-service: webhooks.platform.arb.inc.

​
Envelope format

Every webhook event is wrapped in the same envelope structure:
​
string
required
Unique identifier for this event. Deterministic — retries of the same event produce the same ID, so you can use it for deduplication.
​
string
required
ISO 8601 timestamp of when the event occurred.
​
string
required
The event type. One of docket_filing, phase_changed, or case_closed.
​
object
required
Event-specific payload. Structure depends on the event type.
Example Envelope

​
Event types

​
Retry behavior

Webhooks are delivered through a managed task queue with automatic retries. If your endpoint returns a non-2xx status code or times out (60-second limit), delivery will be retried. The id field is deterministic — the same event always produces the same ID, even across retries. Use it to safely deduplicate incoming webhooks on your end.

​
Best practices

Return a 2xx status code as fast as possible. Do heavy processing asynchronously after acknowledging receipt.
Store the id of each processed webhook. If you receive the same ID again, skip processing — it is a retry.
Webhooks include the header x-service: webhooks.platform.arb.inc. While not a cryptographic signature, you can use it as a basic check along with keeping your webhook URL secret.
Webhooks may arrive out of order. Use the timestamp field and your own case state to handle this gracefully.