Settingsintermediate

Recipe — Fire a webhook when a case closes

When a case closes with a specific tag (e.g. VIP-Refund), POST a webhook to a downstream system with the case ID, contact, and any relevant custom fields. The universal escape hatch for systems Atender doesn't natively integrate with.

5 min read

Recipe — Fire a webhook when a case closes

Case-close webhooks are temporarily deferred while Atender’s cases workflow is being updated. This recipe will return when case-close triggers are configurable again.

If you need to notify a downstream system today, use a conversation-based automation with a webhook action, or have your downstream system call Atender through the API instead.

What this rule does

This recipe is coming soon.

The intended workflow is:

  • Trigger: A case is closed.
  • Condition: Case has the VIP-Refund tag.
  • Action: POST a templated JSON payload to your downstream system.

At the moment, the Case closed trigger and case-scoped webhook payloads are not available in the automation builder.

Before you start

For now, do not build a case-close webhook rule from this recipe. Instead, choose one of these patterns:

  • Use a conversation-based automation trigger and the Webhook action if the event you care about can be represented from the conversation workflow.
  • Use the Atender API if your downstream system needs to query or update Atender directly.
  • Store credentials for outbound or inbound integrations securely, and rotate them if they are shared with an external system.

Build it

Case-close webhook rules are not currently configurable.

When case-close triggers are available again, this recipe will include the exact trigger, condition, action, header, and payload steps. Until then, do not create a rule that depends on case.* merge tags or a Case closed trigger.

Body template

A case-close body template is not currently supported because case-close webhooks are not configurable.

For conversation-based webhook rules, build the payload from the conversation fields available in that rule’s merge-tag context. Keep the payload shape aligned with what your downstream system expects, and avoid relying on case.id, case.human_id, case.closed_at, or other case-only fields until case triggers return.

Idempotency

Any webhook receiver should still be idempotent. Webhook actions can fire more than once for the same logical event under unusual conditions such as network retries, manual re-runs, or re-triggers from edits.

For conversation-based webhooks, key duplicates on a stable conversation identifier or on an idempotency key generated by your receiver.

Throttling

Add a rule throttle if your downstream system has rate limits. Common pattern: Global, 60 per minute to protect a small downstream service from a burst of automation events.

Verify it worked

For conversation-based webhook rules, trigger the conversation event in a test conversation. Check Manual Executions for the rule; expand the run and read the webhook action’s response. You’re looking for:

  • HTTP 2xx status code from the receiver
  • The expected response body (your receiver’s “ok” payload, an idempotency key it returned, etc.)

If the receiver returns non-2xx, the action shows as failed and the response body is captured in the log — read it to debug.

Variants

  • Multiple downstream systems. Use multiple webhook actions in the same branch — they’ll fire in sequence. If you need them parallel, that’s not currently supported; split into multiple rules with the same trigger.
  • Different payloads by conversation state. Use branches to send different webhook payloads based on the fields and tags available in the conversation context.
  • Include a conversation link. Add a conversation URL or transcript link if that field is available in the rule context so the downstream system has a deep link back to the source.
  • Authenticate the request. Add a custom header carrying a shared secret (e.g. X-Shared-Secret: your-token) so the receiver can reject requests that don’t come from your rule. Headers are static — the action can’t compute per-request signatures. If you need cryptographically signed deliveries, use webhook subscriptions instead, which sign every delivery with HMAC-SHA256.

Troubleshooting

  • Symptom: You cannot find the Case closed trigger. Fix: Case-close webhooks are not currently configurable. Use a conversation-based webhook/API pattern until case-close triggers return.

  • Symptom: Receiver doesn’t see the POST. Fix: Open Manual Executions and read the action’s response. If the action shows success but the receiver disagrees, the URL is wrong or being intercepted by a proxy. If the action shows a network error, the URL is unreachable from Atender’s egress IPs — confirm DNS and any IP allowlists.

  • Symptom: Receiver returns 401. Fix: Bearer token is stale or the wrong header name. Some systems expect X-Auth-Token rather than Authorization.

  • Symptom: Receiver returns 422 with a “missing field” error. Fix: A merge tag resolved to empty. Confirm the field exists in the current rule context. Case-only merge tags are not available in conversation-based webhook rules.

  • Symptom: Webhook fires multiple times for one event. Fix: Add an appropriate throttle. Make sure the receiver is idempotent regardless.

See also

Tags

Recipe
Back to Settings