Action webhooks and secrets
Found this helpful? Share it:
Found this helpful? Share it:
A webhook trigger turns an Action into an endpoint: anything that can send an HTTP request can start it, and the request body becomes the event the prompt can read.
Choose the webhook trigger and the Action gets a URL of its own. It is the same address for the life of the Action, so a sender configured once keeps working.
The secret is the only credential the endpoint accepts. It is shown once, when it is created, and never again: store it in the sender's secret store at that moment. Every request carries it as a bearer token.
POST https://idapt.app/api/v1/automations/<id>/fire
Authorization: Bearer <secret>
Content-Type: application/json
{ "title": "Anything your prompt can read" }The webhook panel can send a test request with the secret already filled in. It starts a real run, which is the fastest way to see the payload reach the prompt, and it costs what a normal run costs.
Rotate the secret when it may have leaked, or on a schedule if your security policy asks for one. The new secret is shown once and the old one stops working immediately, so update the sender in the same sitting.
There is no overlap period. If you rotate before the sender is updated, its requests are refused until it carries the new secret.
Every failure looks the same from outside: a missing secret, a wrong secret, a paused Action and an Action that does not exist all return one unauthorised answer. That is deliberate, because a different answer per case would tell a stranger which Actions exist. Repeated attempts from one address are rate limited before the secret is even checked.
Related articles
Was this helpful?
POST https://idapt.app/api/v1/automations/<id>/fire
Authorization: Bearer <secret>
Content-Type: application/json
{ "title": "Anything your prompt can read" }POST https://idapt.app/api/v1/automations/<id>/fire
Authorization: Bearer <secret>
Content-Type: application/json
{ "title": "Anything your prompt can read" }