Webhooks
Receive real-time notifications when workflow executions complete via HTTP webhooks.
Sola can send webhook notifications to your server when workflow executions complete. This allows you to build event-driven integrations without polling the status endpoint.
Overview
When a workflow execution reaches a terminal state (completed, failed, or cancelled), Sola sends an HTTP POST request to the webhook URL you configure on the workflow. The payload contains the execution results, including all output data.
Configuring Webhooks
Webhooks are configured per workflow in the Sola dashboard workflow editor. Each workflow can have multiple webhook endpoints. To do so:
- Open the workflow you want to configure the webhook for.
- Go to the editor (hit "Edit workflow").
- Click the gear ⚙️ icon at the top right corner to open the "Workflow Settings" page.
- Click "Events".
Each webhook has:
- Name: A descriptive label for the webhook
- Webhook URL: The endpoint that will receive the POST request
- Headers: Optional custom headers to include in the request (e.g., for authentication)
Both the webhook URL and header values support variables.
Webhook Payload
When an execution finishes, Sola sends a POST request with a JSON payload following the schema below:
{
"executionId": "uuid",
"workflowId": "uuid",
"workflowName": "My Workflow",
"status": "SUCCESS",
"statusDescription": "Optional details about the status",
"createdAt": "2026-01-15T10:00:00.000Z",
"lastUpdatedAt": "2026-01-15T10:05:00.000Z",
"startedAt": "2026-01-15T10:00:30.000Z",
"finishedAt": "2026-01-15T10:05:00.000Z",
"variableData": {
"inputVar1": "value1",
"inputVar2": "value2"
},
"scrapeData": {
"scrapedField1": "scraped value"
},
"emailData": {
"From": "[email protected]",
"Subject": "Email subject"
},
"documentData": {
"extractedField": "extracted value"
},
"artifacts": [
{
"uri": "https://presigned-s3-url.example.com/artifact.pdf",
"filename": "artifact.pdf"
}
],
"contextKey": "my-context-key"
}Payload Fields
| Field | Type | Description |
|---|---|---|
executionId | string (UUID) | Unique identifier for the execution |
workflowId | string (UUID) | ID of the workflow that was executed |
workflowName | string | Name of the workflow |
status | string | Terminal status: SUCCESS, FAILED, or CANCELLED |
statusDescription | string | null | Additional details about the execution status |
createdAt | string (ISO 8601) | When the execution was queued |
lastUpdatedAt | string (ISO 8601) | When the execution was last updated |
startedAt | string (ISO 8601) | When the execution began running |
finishedAt | string (ISO 8601) | When the execution completed |
variableData | object | Input variable name/value pairs (private variables excluded) |
scrapeData | object | Scrape step outputs (private variables excluded) |
emailData | object | Email trigger fields such as From, To, Subject (private excluded) |
documentData | object | Document AI-extracted fields (private variables excluded) |
artifacts | array | Presigned S3 URLs for execution artifacts (downloads, screenshots) |
contextKey | string | null | Browser context key used, if applicable |
Artifact URLs expire after 7 days. If you need to retain artifacts, download them promptly after receiving the webhook.
Private variables are excluded from variableData, scrapeData, emailData, and documentData in the webhook payload for security.
Custom Headers
You can add custom headers to webhook requests for authentication or routing purposes. Each header is a key-value pair. Both the key and value support template variables.
Example use cases:
Authorization: Bearer your-tokenfor authenticating with your serverX-Workflow-Id: {{workflowId}}for routing on your end
Retry Behavior
By default, webhook deliveries are not retried. If your endpoint returns a non-2xx status code or is unreachable, Sola records the failure and continues without attempting redelivery.
If you'd like Sola to retry failed webhook deliveries, ask your Customer Success Representative to enable webhook retries for your organization. When enabled, Sola automatically retries deliveries that fail with any of the following responses:
408 Request Timeout429 Too Many Requests5xx server errors
See the attempts interval below:
| Attempt | Interval |
|---|---|
| 1 | Immediate (initial delivery) |
| 2 | 30 seconds after 1st attempt |
| 3 | 60 seconds after 2nd attempt |
Retries do not cover other failure modes, including 4xx responses other than 429, invalid URLs, or network-level errors such as an unreachable host or a connection timeout. Even with retries enabled, your endpoint should still respond promptly with a 2xx status whenever possible.
Updated about 1 month ago
