Letterbook
All docs

Letterbook Docs

Call webhooks from AI workflows

Let Letterbook trigger approved internal workflows while resolving support tickets.

Last updated June 25, 2026

What this guide covers#

Webhook actions let Letterbook trigger approved internal workflows while a support conversation is being resolved.

Use webhooks for narrow, well-defined operations that your support team already performs manually, such as resending a receipt, extending a trial, applying a courtesy credit, or starting an account repair job.

Setup steps#

  1. Choose one support action to expose.
  2. Create a server-side webhook endpoint for that action.
  3. Define the action name, description, required inputs, and expected output.
  4. Authenticate requests from Letterbook.
  5. Validate every input on your server.
  6. Return clear success and error responses.
  7. Require human approval before risky or irreversible actions.
  8. Test the action from a realistic support ticket.

Good webhook candidates#

  • Extend a free trial
  • Re-send a receipt
  • Trigger an internal account repair job
  • Apply a courtesy credit
  • Re-sync a customer's entitlement state
  • Open an engineering escalation with a structured bug report
  • Send a password-reset or account-verification email

Avoid broad webhooks such as run_admin_task or update_customer. Narrow actions are easier to review, safer to approve, and easier for the AI to choose correctly.

Request design#

Keep inputs explicit and support-safe. A refund action might accept a customer ID, payment ID, amount, reason, and idempotency key. It should not accept arbitrary SQL, arbitrary API paths, or unrestricted JSON patches.

Return a response that a teammate can understand:

  • What action was attempted
  • Whether it succeeded
  • What changed
  • What the customer should be told
  • What to do if it failed

Approval rules#

Require approval when an action can:

  • Move money
  • Cancel or downgrade service
  • Change account ownership or access
  • Delete data
  • Send a message to the customer outside the current reply
  • Trigger a workflow with external side effects

Lower-risk actions, such as fetching a status or resending a receipt, can usually use lighter review once tested.

Operational guardrails#

  • Log every action with the conversation ID, customer ID, inputs, result, and approving teammate.
  • Use idempotency keys for actions that might be retried.
  • Return safe error messages that do not expose secrets.
  • Add rate limits to protect internal systems.
  • Keep destructive actions reversible where possible.