Introduction
Overview
Deel Webhooks deliver real-time notifications for key platform events, allowing you to build efficient and responsive integrations without relying on constant polling.
- Real-time Updates: Receive notifications as events occur
- Secure Delivery: Every payload is signed using SHA256
- Flexible Subscriptions: Manage webhook subscriptions via API or Developer Center
Use Cases
Here are a few examples of how you might use webhooks:
Syncing Data
Automatically update your system when new contracts are created or modified in Deel.
Real-time Notifications
Trigger alerts or workflows in your internal tools when important events happen.
Workflow Automation
Start external processes based on specific events like contract signatures or payment completions.
Webhooks vs Polling
Understanding when to use webhooks versus polling helps you build more efficient integrations.
Use polling if:
- Updates are frequent
- You don’t need updates in real-time
Characteristics:
- Resource-intensive
- Predictable load
- Simpler to implement
Use webhooks if:
- Updates are infrequent
- You need updates in real-time
Characteristics:
- Efficient, event-triggered
- Lower API usage
- Requires endpoint setup
Comparison
How Webhooks Work
When an event occurs in your Deel account, Deel sends an HTTP POST request to your configured endpoint with details about what happened.
Webhook Structure
Each webhook request contains:
Headers
Payload
Security
Every webhook includes these HTTP headers:
Available Events
Deel supports a wide range of webhook events across different services.
Get the complete list: Use the GET /webhooks/events API endpoint to retrieve all available event types and their descriptions.
Webhook Reliability
Deel ensures webhook delivery through an automatic retry mechanism:
Retry Behavior
If your endpoint fails to respond with a 2xx status code, Deel will retry delivery:
After 10 consecutive failures, the webhook subscription is automatically disabled. You’ll need to re-enable it manually through the API or Developer Center.
What Counts as a Failure?
- Non-2xx HTTP status code (400, 401, 403, 500, etc.)
- Connection timeout (endpoint doesn’t respond within 30 seconds)
- Network errors or unreachable endpoint
Best Practices
Respond quickly
Return a 200 OK response within 30 seconds (ideally under 5 seconds).
Why? Prevents timeouts and retry storms. Process webhooks asynchronously if needed:
Handle duplicate events
Webhooks may be delivered more than once due to network issues or retries.
Solution: Make your handlers idempotent by tracking processed event IDs:
Subscribe selectively
Only subscribe to events your application needs.
Why? Reduces unnecessary traffic and processing. You can always add more events later.
Implement reconciliation
Don’t rely solely on webhooks. Run periodic reconciliation jobs to catch any missed events:
Get Started
Ready to set up webhooks? Choose your path: