Create a destination
1
Open Webhooks
Choose Webhooks in the sidebar and create a destination. Enter a descriptive name, a receiver URL you control, and the HTTP method your receiver accepts.
2
Add authentication
Enter headers such as
Authorization: Bearer YOUR_RECEIVER_TOKEN. Keep secrets in headers, not the URL or template data. Selecting an authentication style does not create the header for you.3
Set timeout and delivery behavior
The default timeout is 10,000 ms; the accepted range is 1,000–60,000 ms. Configure retries deliberately for your receiver and the interaction flow described below.
4
Attach and verify
Select the destination in a button webhook or modal submission action. Send to a test channel, trigger the action, and confirm the request in your receiver and LithoBlocks interaction history.
Payloads and credentials
Payload templates belong to the action. Use payload variables, includingcontext.* for original send data, user.id for the person interacting, and submission.values.* for modal values.
Destination API responses mask header values as •••. A PATCH that omits headers preserves credentials; a supplied object replaces all headers, and {} clears them. Do not send masked values back.
Retries and uncertain delivery
A timeout does not prove the receiver did nothing. Give business operations a stable identifier, such as a request ID plus action, and deduplicate them at your receiver. Destination retry settings do not apply uniformly to every flow. Authored modal submissions save a receipt, close, and dispatch asynchronously; failed or uncertain submission attempts are not automatically retried, even when destination retries are enabled. A message-update failure does not resend the webhook. See Modal submissions. Destination test requests also do not retry automatically. Before retrying any uncertain delivery, inspect the receiver’s records.API management and testing
Reads usedestinations:read; create, edit, delete, and test operations use destinations:write (admin or owner). See Destination API for request bodies, masking, deletion constraints, and signed tests.
Ordinary button and submission webhooks use the configured headers. Do not expect the signature used by the destination-test API on ordinary deliveries. A test endpoint may be unavailable when your receiver’s HTTPS host is not enabled for tests; contact support rather than substituting an internal address.
Deactivating a destination stops dispatch. Deleting it can break buttons in old sent messages even when no current template references it.
Button webhooks · Modal submissions · Logs