Webhook delivery and event triggers.
OneOrg lets admins create outbound webhooks that send selected workspace events to external systems, with signing, test delivery, retries, and delivery history built into the configuration flow.
Subscribe to outbound events
Webhooks are configured from the organization admin area. Each webhook has a name, destination URL, subscribed event types, and a signing secret. The event list controls which OneOrg activity should be sent out, so admins can choose a narrow stream instead of exporting every workspace event.
The webhook screen supports the full lifecycle: create, update, disable or delete, test delivery, and delivery review. Testing lets admins confirm that the destination can receive OneOrg's payload before relying on the webhook in a production workflow.
Security is built into the user-facing setup. OneOrg signs deliveries so the receiving system can verify that the request came from OneOrg. The secret is part of the configuration, but it is not something general users need to handle after setup.
Delivery history gives admins an operational view. They can see whether deliveries succeeded, how long they took, how many attempts were made, and what error was reported when a destination failed.
That makes webhooks manageable after setup. Admins can inspect failures from inside OneOrg instead of guessing whether the problem is the event selection, the destination URL, or the receiving system.
Build webhooks from the receiving system backward. Decide what the destination needs to know, then subscribe only to those events. Give the webhook a name that identifies the downstream workflow and owner. Test before relying on it, then check delivery history after the first real event. If delivery fails, use the history view to separate destination downtime, signature mismatch, and wrong event selection. Avoid broad event subscriptions unless the receiver is intentionally acting as a full audit or sync target. Narrow subscriptions are easier to debug and less likely to expose activity the receiver does not need.
Debug and limit delivery
Use webhooks when an external system needs to react to OneOrg events: syncing activity, triggering an external workflow, updating an internal system, or recording events outside OneOrg. Use the test action before treating a webhook as live.
Do not use webhooks when the goal is to pull data into OneOrg. Use integrations for connected provider data. Do not assume exactly-once delivery; receiving systems should tolerate retries and duplicate event handling.