Skip to main content
Outbound webhooks notify your application when an EigenPal run is created or changes status. They are useful when a run takes too long to keep an API request open and you do not want to poll the Runs API. Webhooks are configured per organization in Webhooks in the EigenPal dashboard. An endpoint can subscribe to either or both supported events:
  • run.created — a top-level workflow or agent run was created.
  • run.status_changed — a top-level run moved from one persisted status to another.
Runs created internally by an action.invoke-workflow step do not emit webhook events.

​
Create an endpoint

1

Open Webhooks

Select Webhooks in the dashboard sidebar and choose Add webhook.
2

Enter the destination

Add a descriptive name and an HTTPS URL that accepts POST requests.
3

Choose events

Select run.created, run.status_changed, or both.
4

Add optional headers

Add credentials such as an Authorization header when your receiver requires them. Header values are encrypted and are not shown again.
5

Store the signing secret

Copy the whsec_... signing secret from the creation dialog or the endpoint page. Use it to verify that webhook requests were sent by Eigenpal.
If you lose or suspect exposure of the signing secret, disable or delete the endpoint and create a replacement. Secret rotation is not available yet.

​
Receive events safely

Webhook delivery is asynchronous and at least once. Your receiver should:
  1. Verify the signature.
  2. Store or deduplicate by the event id.
  3. Return a 2xx response quickly.
  4. Process expensive work asynchronously.
See the webhook receiver reference for request headers, event schemas, run statuses, signature verification code, and retry behavior.

​
Test an endpoint

Use Send test from an endpoint page. Test requests pass through the same queue, signing, security checks, and delivery history as production events and set test to true. The included run and automation IDs are synthetic and do not identify persisted resources.
Return 2xx as soon as the event is durably accepted by your application. A slow response can time out even when your application eventually completes its work, causing a duplicate attempt.