Overview
Firstwork supports both outgoing webhooks (sending events to external services) and incoming webhooks (receiving events from external services). Webhooks enable real-time integration with any system that supports HTTP callbacks.Outgoing Webhooks
Webhook Action
The Webhook Action in automations sends HTTP requests to external endpoints:| Configuration | Description |
|---|---|
| URL | Target endpoint URL |
| Method | HTTP method (POST, PUT, PATCH) |
| Headers | Custom HTTP headers (auth tokens, content type) |
| Body | Request payload with variable support |
| Timeout | Request timeout duration |
| Retry Policy | Retry configuration for failures |
Payload Format
Webhook payloads support Object Graph variables:Common Outgoing Webhook Use Cases
- Notify external ATS of stage changes
- Update CRM with candidate status
- Trigger external workflows (Zapier, Make, n8n)
- Sync data with HRIS systems
- Send events to analytics platforms
Incoming Webhooks
Webhook Triggers
External systems can trigger Firstwork automations via incoming webhooks. Each webhook trigger gets a unique URL that external services can POST data to. Example payload:Webhook Trigger Configuration
Each webhook trigger has:- A unique URL that acts as the endpoint
- Associated automation that fires when called
- Input variable mapping from the webhook payload
- Authentication requirements
Setting Up Incoming Webhooks
Create an automation with a Webhook trigger
In the automation builder, select “Webhook” as the trigger type.
Configure input variables
Map fields from the incoming webhook payload to automation input variables.
Security
Authentication
Incoming webhooks support:- API key authentication — Bearer token in the Authorization header
- Signature verification — HMAC signature validation
- IP allowlisting — Restrict to known IP addresses
Best Practices
Use HTTPS endpoints
Use HTTPS endpoints
Always use HTTPS for webhook URLs to encrypt data in transit.
Validate payloads
Validate payloads
Verify webhook signatures or tokens to ensure requests are legitimate.
Handle retries idempotently
Handle retries idempotently
Design your webhook handlers to be idempotent — the same event delivered twice should not cause duplicate actions.
Monitor delivery
Monitor delivery
Track webhook delivery status in automation execution logs and set up alerts for failures.
Retry Policy
Outgoing webhooks are retried on failure:- Initial retry — After 30 seconds
- Second retry — After 2 minutes
- Third retry — After 10 minutes
- Final retry — After 1 hour
- Retries stop after 4 attempts or a successful delivery