Reference
Webhooks and holds
A hold is resolved out of band. How a human steps in depends on your tenant type, and webhooks are how your own systems stay in the loop.
How holds reach a human, by tenant type
| Tenant type | Where the human reviews | What Selah stores |
|---|---|---|
| enterprise | The review queue inside the Selah dashboard, with full context and a summary, plus email | The held item and its context, inside Selah |
| private | An alert in the Selah panel, plus email | The held item and its context, inside Selah |
| platform | Your own product, via a webhook | Nothing about the escalation; the context travels in the webhook |
Enterprise and private resolve inside Selah. Platform resolves in your product, and Selah keeps none of the conversation.
Events
The engine emits these to your registered webhook endpoints. Delivery is best effort and fail safe, so a delivery failure never changes a decision.
| Event | When it fires |
|---|---|
action.held | An action evaluation returned hold |
review.resolved | A human resolved a held review item |
output.escalated | A response validation escalated to a human, the primary signal for platform tenants |
output.blocked | A response validation hard blocked a reply |
Payload shape
Payloads carry the tenant or sub tenant, the reason, and the context needed to act. Confirm the exact fields in the live OpenAPI. An escalation looks like:
{
"event": "output.escalated",
"tenant": "northwind-retail",
"reason": "response not grounded in policy source",
"context": { "response": "the drafted reply", "rule": "policy_grounding", "thread": [] }
}
Handling a webhook
- Verify the request is genuinely from Selah before trusting it. Validate the signature or shared secret on the delivery.
- Respond quickly with a success status, then do your work asynchronously. Do not block the delivery on slow processing.
- Route the item to the right reviewer in your interface, for a platform tenant, or react to a resolution, for any tenant.
- Be idempotent. The same event may be delivered more than once; deduplicate on the event identifier.
Reacting to holds without webhooks
If you do not run webhooks, an enterprise or private tenant can work entirely from the dashboard: holds appear in the review queue or the panel, and a person resolves them there. Webhooks are what let your own systems know in real time; they are required for the platform model, where resolution happens in your product.
Notifications
Independently of webhooks, the engine sends email on holds, denials, response escalations, and a daily summary when agents hit a disabled service. Each is a toggle on the tenant, and recipients are the tenant notification addresses plus the tenant operators. A block or escalation always notifies, subject to those toggles.