Real-Time Email Tracking with Webhooks
Why webhooks for email tracking
Polling an API to check email status is inefficient and slow. Webhooks flip the model: instead of your application repeatedly asking 'Is it delivered yet?', the email API tells your application the moment something happens. This gives you real-time visibility into your email pipeline without wasting API calls. AISend sends webhooks for every email lifecycle event: queued (accepted by our API), sending (being transmitted to the recipient's server), sent (accepted by the recipient's server), delivered (confirmed in the inbox), opened (recipient opened the email), clicked (recipient clicked a link), bounced (delivery failed), and complained (recipient marked as spam). Each event includes a timestamp, the email ID, and event-specific metadata.
Setting up your webhook endpoint
Create an HTTP POST endpoint in your application that accepts JSON payloads. In a Next.js app, this would be an API route; in Express, a POST handler; in Django, a view. The endpoint should return a 200 status code quickly — process the webhook asynchronously (e.g., add to a job queue) rather than doing heavy work in the request handler. AISend will retry failed webhook deliveries (non-2xx responses) with exponential backoff for up to 24 hours. Register your webhook URL in the AISend dashboard or via the API, and specify which events you want to receive. For most applications, subscribing to delivered, bounced, and complained events is sufficient.
Verifying webhook signatures
Always verify webhook signatures to ensure the request is genuinely from AISend and hasn't been tampered with. Each webhook request includes an x-webhook-signature header containing an HMAC-SHA256 signature of the request body using your webhook secret (found in your dashboard). To verify, compute the HMAC-SHA256 of the raw request body using your secret, and compare it to the signature header using a timing-safe comparison function. Never skip signature verification — without it, anyone who discovers your webhook URL can send fake events to your application, potentially causing it to mark valid emails as bounced or trigger unauthorized actions.
Common webhook patterns
Track delivery status in your database: when you send an email, store the AISend email ID with a status of 'sent'. When you receive a 'delivered' webhook, update the status. When you receive a 'bounced' webhook, mark the status as failed and add the recipient to your suppression list. For user-facing features, webhooks enable real-time email status displays — show users whether their invitation email was delivered, or alert support when a critical email bounces. For analytics, aggregate webhook events to calculate deliverability rates, average delivery times, and engagement metrics. This data helps you identify and fix deliverability issues before they impact your users.
Handling webhook failures gracefully
Your webhook endpoint should be idempotent — receiving the same event twice should not cause problems. AISend may retry webhooks if your endpoint returns an error, so you might receive duplicate events. Use the event ID to deduplicate. If your application is down, AISend queues webhook events and retries them when your endpoint comes back online. Store webhook events in a durable queue (Redis, SQS, or a database table) before processing them, so you don't lose events if your processing code fails. Monitor your webhook processing for errors and latency — a backlog of unprocessed webhooks means you're operating with stale email status data.
Ready to Send Smarter Emails?
1,000 emails/month free. No credit card required.