Skip to main content

How Webhooks Are Processed

RevyOps webhook endpoints receive POST requests from your sending platforms. For several integrations, a 200 response confirms RevyOps received the event, not necessarily that it has finished processing yet, so an event’s effects (a new email record, an updated contact) can show up a short time after the response comes back.

Endpoint Reference

Per-Workspace Webhooks

The endpoints below are scoped to a single workspace. Use them when each workspace has its own sending platform account.

Agency-Level (Global) Webhooks

Use these when a single sending platform account is shared across multiple workspaces. RevyOps sends a campaign event to a workspace when the campaign name contains one of the keywords set for that workspace on the Campaign Mapping page, and that workspace has the platform ticked under Integrations with mapping. Two platforms add a second route. An EmailBison event that names its EmailBison workspace goes to the RevyOps workspace whose keyword is that EmailBison workspace name, ignoring capitals, and whose saved Email Bison API URL is on the same EmailBison domain. A HeyReach tag event carries no campaign name, so it goes to each workspace that has already sent that lead LinkedIn messages through HeyReach.
An event that reaches no workspace still gets a 200 response, so the sending platform’s log shows a successful delivery while nothing arrives. Three settings cause it:
  • The keyword doesn’t match the campaign name exactly as typed, including case. A keyword Acme matches a campaign named Acme Q3 Outbound, and misses one named acme q3 outbound.
  • The workspace doesn’t have the platform ticked under Integrations with mapping.
  • The agency_id in the URL is wrong. Copy the URL from the Campaign Mapping page instead of typing it.
A campaign name that contains keywords for two workspaces reaches both.
Once a workspace has a platform ticked under Integrations with mapping, RevyOps ignores events sent to that workspace’s own per-workspace URL for that platform, so the same event can’t arrive twice, and still answers them with a success. If you tick Instantly for a workspace but its Instantly account still sends to the per-workspace URL, nothing from it arrives.

When a Webhook Isn’t Allowed for a Workspace

If an agency’s permissions restrict which integrations a workspace can use and the webhook’s integration isn’t in that list, or the workspace can’t be resolved at all, the request is rejected before your payload is read, and you’ll see a 401 Unauthorized response.
The permission check can take up to 5 minutes to pick up a change. If you enable an integration for a workspace, calls can keep failing with 401 for a few minutes afterward before the change takes effect.

Unowned Events

RevyOps can also check that an inbound event actually belongs to the workspace it claims to be for. Where this check is enforced, an event that fails it gets a 200 response with body {"message": "Event not owned by this workspace"} and is not processed further. Because the status is 200, the sending platform’s delivery log shows the event as delivered, so read the response body when events go missing.

Webhooks and Workspace Archiving

Archiving a workspace in RevyOps automatically disables that workspace’s EmailBison and HeyReach webhooks, so an archived, no-longer-billed workspace doesn’t keep sending events. Unarchiving a workspace restores them. Other platforms’ webhooks are not automatically torn down on archive.

Debugging Webhook Events

If events are not appearing in RevyOps:
  1. Confirm the webhook URL includes your correct client_id
  2. Check your sending platform’s webhook delivery logs for any error responses, and read the body of 200 responses too, since a dropped event also returns 200
  3. Verify the platform is sending the correct event types
  4. If you use a global webhook, check the campaign name against the workspace’s keywords on the Campaign Mapping page
  5. Use the Emails section in RevyOps to see if any records arrived with unexpected data
Most sending platforms show webhook delivery history with request/response details. Check these logs first when debugging connectivity issues.