Skip to main content
POST
Create webhook subscription
Webhook subscriptions tell Tilta where to send event notifications. When you create a subscription, you provide an event type – either a specific event or a parent prefix such as FACILITY – and a destination_url. Tilta delivers an HTTP POST request to that URL whenever a matching event occurs. The response includes a signature_key that you must store securely: it is shown only once and cannot be retrieved again.
The signature_key is only visible in this creation response. Tilta does not store or re-expose it. If you lose it, rotate the key to get a new one.

Verifying webhook signatures

Every webhook request Tilta sends includes an X-Tilta-Signature header. Compute an HMAC-SHA256 digest of the raw request body using your signature_key and compare it to the header value to confirm the request is genuine.
Subscribe to parent prefixes (e.g. FACILITY, ORDER) during development so you can inspect all event shapes in one place. Switch to specific leaf-event subscriptions in production to reduce noise and tighten access control.

Authorizations

Authorization
string
header
required

Your Tilta API key, sent as Bearer <key>.

Body

application/json
destination_url
string<uri>
required

Where the webhook should be sent to. This must be an endpoint that handles POST requests.

type
enum<string>
required

The webhook's type. Supports the hierarchical dot-notation taxonomy; subscribing to a parent (e.g. FACILITY) implicitly subscribes to every descendant event (e.g. FACILITY.CREATION.ACCEPTED). Other valid values include ORDER.CONFIRMED and INVOICE.DUE.

Available options:
BUYER,
BUYER.CREATED,
BUYER.UPDATED,
FACILITY,
FACILITY.CREATION,
FACILITY.CREATION.ACCEPTED,
FACILITY.CREATION.IN_REVIEW,
FACILITY.CREATION.REJECTED,
FACILITY.EXPIRED,
FACILITY.FROZEN,
FACILITY.INCREASE,
FACILITY.INCREASE.ACCEPTED,
FACILITY.INCREASE.IN_REVIEW,
FACILITY.INCREASE.REJECTED,
FACILITY.RENEWAL,
FACILITY.RENEWAL.ACCEPTED,
FACILITY.RENEWAL.IN_REVIEW,
FACILITY.RENEWAL.REJECTED,
FACILITY.UNFROZEN,
INVOICE,
INVOICE.CLOSED,
INVOICE.CREATED,
INVOICE.DUE,
INVOICE.FILE,
INVOICE.FILE.CREATED,
INVOICE.FILE.DELETED,
INVOICE.FILE.REPLACED,
INVOICE.FINANCING,
INVOICE.FINANCING.PAID_OUT,
ORDER,
ORDER.CANCELLED,
ORDER.CLOSED,
ORDER.CONFIRMED,
ORDER.DISBURSED,
ORDER.EXPIRED
Example:

"FACILITY.CREATION.ACCEPTED"

Response

destination_url
string<uri>
required

Where the webhook should be sent to. This must be an endpoint that handles POST requests.

type
enum<string>
required

The webhook's type. Supports the hierarchical dot-notation taxonomy; subscribing to a parent (e.g. FACILITY) implicitly subscribes to every descendant event (e.g. FACILITY.CREATION.ACCEPTED). Other valid values include ORDER.CONFIRMED and INVOICE.DUE.

Available options:
BUYER,
BUYER.CREATED,
BUYER.UPDATED,
FACILITY,
FACILITY.CREATION,
FACILITY.CREATION.ACCEPTED,
FACILITY.CREATION.IN_REVIEW,
FACILITY.CREATION.REJECTED,
FACILITY.EXPIRED,
FACILITY.FROZEN,
FACILITY.INCREASE,
FACILITY.INCREASE.ACCEPTED,
FACILITY.INCREASE.IN_REVIEW,
FACILITY.INCREASE.REJECTED,
FACILITY.RENEWAL,
FACILITY.RENEWAL.ACCEPTED,
FACILITY.RENEWAL.IN_REVIEW,
FACILITY.RENEWAL.REJECTED,
FACILITY.UNFROZEN,
INVOICE,
INVOICE.CLOSED,
INVOICE.CREATED,
INVOICE.DUE,
INVOICE.FILE,
INVOICE.FILE.CREATED,
INVOICE.FILE.DELETED,
INVOICE.FILE.REPLACED,
INVOICE.FINANCING,
INVOICE.FINANCING.PAID_OUT,
ORDER,
ORDER.CANCELLED,
ORDER.CLOSED,
ORDER.CONFIRMED,
ORDER.DISBURSED,
ORDER.EXPIRED
Example:

"FACILITY.CREATION.ACCEPTED"

signature_key
string
required
created_at
number
required

Timestamp indicating when the webhook was created (unix time in seconds).

Example:

1582896122

updated_at
number
required

Timestamp indicating the last time the webhook was updated (unix time in seconds).

Example:

1582896122