Webhook Guides

Webhook to Email

A webhook to email workflow turns selected events into human-readable notifications. It is useful when support, finance, operations, or founders need to see important events without opening logs or building a custom dashboard.

FastHook supports GMAIL destinations for this pattern. A provider sends the webhook to a FastHook source, connection rules filter and shape the event, and the Gmail destination sends a message with templated recipients, subject, text, and optional HTML.

When email is the right destination

Email should be used for events that need human attention, not every machine event. Filter aggressively so a temporary provider burst does not become a noisy inbox incident.

  • Payment failures, subscription cancellations, or manual review events.
  • High-value leads or forms that need a human follow-up.
  • Operational exceptions, not every success event.
  • Low-volume customer-facing or internal notification workflows.

Email template fields

FieldPurposeExample
ToOne or more static or templated recipients.{{payload.owner.email}}
SubjectReadable summary for inbox scanning.New webhook event {{event_id}}
Text bodyPlain-text fallback and audit-friendly content.{{payload}}
HTML bodyOptional formatted message for operators.<p>{{payload.type}}</p>

Create a Gmail destination

Gmail destinations use Google OAuth with the Gmail send scope. FastHook locks this destination to a safe send pace so replay does not flood Gmail all at once.

Create Gmail destination
curl -X POST "https://api.fasthook.io/v1/destinations" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_3b5335b627084a838b" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "High-value lead email",
    "type": "GMAIL",
    "config": {
      "to": ["ops@example.com"],
      "subject": "New lead: {{payload.email}}",
      "text_template": "Lead payload: {{payload}}",
      "auth_type": "GOOGLE_OAUTH_REFRESH_TOKEN",
      "auth": {
        "client_id": "google-client-id",
        "client_secret": "google-client-secret",
        "refresh_token": "google-refresh-token",
        "scope": "https://www.googleapis.com/auth/gmail.send"
      }
    }
  }'

Filter before sending

The most common webhook to email mistake is connecting the email destination directly to all traffic. Put a filter in front of Gmail so only meaningful events create messages.

Email-worthy event filter
{
  "type": "filter",
  "body": {
    "type": {
      "$in": ["lead.created", "invoice.payment_failed", "review.required"]
    }
  }
}

Debug delivery

  • Inspect the accepted request to confirm the provider sent the expected payload.
  • Inspect routed events to confirm the filter matched.
  • Inspect the Gmail attempt for OAuth errors, template mistakes, and rate-limit behavior.
  • Retry one failed event after fixing OAuth, recipients, or template fields.
  • Keep a separate staging email destination for replay tests.

Email workflow design rules

A webhook email should read like an operational summary, not a raw database dump. Put the most important identity fields in the subject, keep the body focused on what changed, and include the event id so support can correlate the message with FastHook request and attempt records.

If the event needs a human action, say what object needs review and why it was routed. If the email is only for audit, keep it low volume and consider Google Sheets instead so teams can sort, filter, and export rows without searching an inbox.

  • Use static recipients for team alerts and templated recipients only when the payload is trusted.
  • Put environment names in the subject so staging and production messages cannot be confused.
  • Keep secrets out of email templates because forwarded messages are difficult to control.
  • Prefer one email per important event over one large digest when immediate action matters.

Related guides