Skip to main content
POST
/
webhook
cURL
curl --request POST \
  --url https://api.slash.com/webhook \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: <api-key>' \
  --data '
{
  "url": "<string>",
  "name": "<string>",
  "legalEntityId": "<string>"
}
'
{
  "id": "<string>",
  "createdAt": "<string>",
  "url": "<string>",
  "name": "<string>",
  "archivedAt": "<string>",
  "pausedAt": "<string>",
  "backingOffUntil": "<string>",
  "disabledAt": "<string>"
}

Documentation Index

Fetch the complete documentation index at: https://docs.slash.com/llms.txt

Use this file to discover all available pages before exploring further.

Authorizations

​
X-API-Key
string
header
required

API key authentication for public API requests.

Keys come in two flavors:

  • Legal-entity-scoped keys are pinned to a single legal entity. Minted via the dashboard under a specific entity; every request acts on that entity.
  • User-scoped keys are pinned to a user and span every legal entity that user has access to. Every request made with a user-scoped key (except GET /legal-entity, which lists the legal entities the user can access) must include an x-legal-entity header naming the legal entity the request is operating on. Requests without the header are rejected with 400. The authenticated user must have an active permission role on the supplied legal entity, otherwise the request is rejected with 403.

Body

application/json
​
url
string
required

The URL that will receive the webhook payload

​
name
string
required
​
legalEntityId
string

The ID of the LegalEntity to create the webhook for. You can get this by calling GET /legal-entity. This field is required unless you are authenticating via API key.

Response

OK

​
id
string
required
​
createdAt
string
required
​
url
string
required

The URL that will receive the webhook payload

​
name
string
required

The name of the webhook

​
status
enum<string>
required

The current status of the webhook endpoint:

  • active: The webhook is enabled and receiving events normally.
  • paused: The webhook has been paused by the user. Events are queued and will be delivered when the endpoint is set back to active.
  • backing-off: The system is temporarily backing off due to delivery failures. Delivery will be automatically retried at backingOffUntil. You can also immediately re-enable by setting status to active via the PATCH endpoint.
  • disabled: The webhook has been automatically disabled due to repeated delivery failures. Re-enable by setting status to active via the PATCH endpoint.
Available options:
active,
paused,
backing-off,
disabled
​
archivedAt
string
​
pausedAt
string

When the endpoint was paused by the user (ISO 8601 timestamp)

​
backingOffUntil
string

When the system will automatically retry delivery (ISO 8601 timestamp). Only present when status is backing-off.

​
disabledAt
string

When the endpoint was automatically disabled due to repeated failures (ISO 8601 timestamp). Only present when status is disabled.