Webhook Integrations
Yess webhook integrations allow you to receive real-time notifications about engagement events in your external systems. When specific events occur in Yess (such as when an engagement is dispatched or when you receive an inbound response), Yess will send an HTTP POST request to your configured webhook endpoint with detailed information about the event.Overview
Webhooks enable you to:- Get notified immediately when engagements are sent
- Track inbound responses and interactions
- Sync engagement data with your CRM or other tools
- Build custom workflows based on Yess events
- Monitor engagement performance in real-time
Setting Up a Webhook
To create a webhook integration, you’ll need to configure:1. Target URL
The HTTP endpoint where Yess will send webhook notifications. This must be:- A valid HTTPS URL (HTTP is not supported for security)
- Publicly accessible from the internet
- Able to accept POST requests
- Responsive (should return a 2xx status code within 30 seconds)
2. Authentication Headers (Optional)
Custom HTTP headers for authenticating webhook requests, such as:- API keys:
Authorization: Bearer your-api-key
- Custom tokens:
X-Webhook-Token: your-secret-token
- Basic authentication:
Authorization: Basic base64-encoded-credentials
3. Event Types
Select which events should trigger webhook notifications:Available Event Types
Event Type | Description |
---|---|
engagement_dispatched | Triggered when an outbound engagement (email, LinkedIn message, etc.) is successfully sent |
inbound_engagement | Triggered when you receive an inbound response (email reply, LinkedIn message, connection request accepted, etc.) |
engagement_status_changed (Coming Soon) | Triggered whenever the status of an engagement is updated (e.g., from pending to sent, failed to delivered, or replied) |
Webhook Payload Structure
All webhook payloads follow a consistent structure containing information about the event, account, lead, engagement, and optionally the sequence.Base Payload Structure
Account Object
Lead Object
Engagement Object
The engagement object varies based on the channel and action:Sequence Object (Optional)
Included when the engagement is part of a sequence:Engagement Channels and Actions
Email Channel
Channel:email
Actions:
new_thread_email
- New email threadfollow_up_email
- Follow-up email in existing threadfollow_on_reply_email
- Response to an inbound email
LinkedIn Channel
Channel:linkedin
Actions:
linkedin_connect
- Connection requestlinkedin_message
- Direct messagelinkedin_inmail
- InMail messagelinkedin_follow_on_reply
- Response to inbound LinkedIn messagelinkedin_group_chat
- Group chat messagelinkedin_group_chat_follow_up_on_reply
- Group chat follow-up
Manual Channel
Channel:manual
Actions:
manual_task
- Manual task or action
Inbound Actions
For inbound engagements, actions include:reply_email
- Email reply receivedreply_linkedin
- LinkedIn message receivedconnection_accepted_linkedin
- LinkedIn connection accepted
Integration Identifiers
Integration identifiers help you map Yess entities to records in your existing systems:Account Integration Identifiers
salesforce_id
- Salesforce Account IDhubspot_id
- HubSpot Company IDoutreach_id
- Outreach Account IDsalesloft_id
- SalesLoft Account ID
Lead Integration Identifiers
salesforce_lead_id
- Salesforce Lead IDsalesforce_contact_id
- Salesforce Contact IDhubspot_id
- HubSpot Contact IDoutreach_id
- Outreach Prospect IDsalesloft_lead_id
- SalesLoft Person ID
Example Webhook Payloads
Email Engagement Dispatched
Inbound LinkedIn Reply
Security Considerations
Webhook Verification
To ensure webhooks are coming from Yess:- Use HTTPS endpoints only
- Implement header-based authentication
- Validate the request structure
- Consider IP allowlisting to Yess IP -> 52.44.59.155
Best Practices
- Validate payloads: Always validate the structure and content of incoming webhooks
- Handle failures gracefully: Implement retry logic and error handling
- Process asynchronously: Handle webhook processing in background jobs to avoid timeouts
- Secure your endpoint: Use authentication headers and validate requests
- Monitor and log: Track webhook deliveries and failures for debugging
Error Handling
Webhook Delivery
Yess will attempt to deliver webhooks with the following behavior:- Timeout: 30 seconds per request
- Retries: Up to 10 attempts with exponential backoff
- Success criteria: HTTP status codes 200-299
- Failure handling: After max retries, delivery attempts stop
Recommended Response Handling
Your webhook endpoint should:- Return appropriate HTTP status codes (200-299 for success)
- Respond quickly (under 30 seconds)
- Handle duplicate deliveries gracefully (webhooks may be retried)
- Log received webhooks for debugging
Common HTTP Status Codes
200 OK
- Webhook received and processed successfully400 Bad Request
- Invalid payload format401 Unauthorized
- Authentication failed500 Internal Server Error
- Processing error (will trigger retry)
Testing Your Webhook
Testing Tools
- Use tools like ngrok to create a public endpoint for local testing
- Test with webhook testing services like webhook.site
- Use curl or Postman to simulate webhook payloads
Sample Test Payload
You can use this sample payload to test your webhook endpoint:Troubleshooting
Common Issues
Webhook not being received:- Check that your endpoint is publicly accessible
- Verify HTTPS is being used
- Confirm your endpoint returns 2xx status codes
- Check if authentication headers are configured correctly
- Implement idempotency using the
engagement.yess_id
- Handle retries gracefully in your application
- Some fields may be null or missing if data isn’t available
- Integration identifiers are only included when the entity has been synced from that system
- The
sequence
object is only included for sequence-based engagements
- Ensure your endpoint responds within 30 seconds
- Process webhooks asynchronously if heavy processing is needed
- Return a success status immediately and process in the background