Build a Multi-Channel Notification Workflow

Give each business event a stable internal ID, such as invoice.paid:inv_123, and persist the recipient, purpose, preference snapshot, and policy version. Then track each channel attempt separately. A useful model distinguishes business state from transport state:

• Business event: what happened and whether a notice is required.
• Attempt: channel, template version, destination, Senddio message ID, and timestamps.
• Outcome: queued, provider accepted, delivered, failed, expired, or suppressed where those states are available.

Use a transactional outbox or equivalent durable handoff between the business transaction and the worker queue. This prevents a database change from succeeding while its notification task disappears. Keep sensitive payloads minimal and apply access and retention controls to notification records.

Choose based on urgency, user preference, information sensitivity, destination availability, cost, and the channel’s setup rules. A non-urgent product update may belong in email; a time-sensitive sign-in code may need a verified SMS route; an internal incident may go to a team channel. These are examples, not universal rules. For mobile push, also account for client token registration and platform delivery behavior described in the official Firebase Cloud Messaging documentation.

Honor opt-outs and channel-specific consent before creating an attempt. Confirm that the sender is configured and that the content meets the selected provider’s requirements. For example, WhatsApp has platform-specific template and conversation rules; review the current WhatsApp API documentation for provider-side constraints. See Senddio’s WhatsApp setup guide and other channel references for product configuration details.

Keep provider calls out of user-facing database transactions. A background worker can re-check suppression and preferences, render the selected template, submit the channel request, and persist the API result. This lets the product acknowledge its own event while notification processing continues independently.

curl https://api.senddio.com/v1/send \
  -H "Authorization: Bearer $SENDDIO_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "sms",
    "from": "+14155552671",
    "to": "+14155550123",
    "body": "Your delivery is scheduled for tomorrow."
  }'

Persist the response’s message identifier and the accepted state before acknowledging the job. HTTP 202 means accepted into the queue, not delivered. Consult the current Senddio API docs for the endpoint, response fields, message lookup, and webhook configuration.

Configure webhooks or poll the documented message status endpoint to learn what happened after submission. Verify webhook authenticity using the mechanism documented by Senddio, write the event to durable storage, and respond promptly. Process from your own queue so a downstream timeout does not lose the provider event.

Webhook deliveries can be repeated or arrive after later events. Deduplicate by a stable event identifier where available, preserve event timestamps, and avoid overwriting a more recent known state with an older event. Your webhook consumer should be safe to retry. Keep raw payload retention limited and avoid logging message bodies that contain private information.

Fallback needs a policy per notification class. Specify which terminal failure permits a retry, how long to wait, which alternate channel is allowed, and when to stop. Do not fall back merely because the initial API call returned 202: the message may still be processing or may arrive after the alternate send.

Use a unique attempt record and a compare-and-set transition so two workers cannot launch the same fallback at once. Consider a grace period and whether a late original delivery would make the fallback confusing. Do not resend one-time codes or sensitive notices to another destination without applying the same security and preference checks. Track your own event IDs; do not assume undocumented idempotency or automatic cross-channel retries.

Monitor queue age, accepted requests, delivery outcomes, terminal failures, webhook lag, and fallback rate by channel and message class. Alert on sustained queue growth or a sudden rise in failures. Keep a manual pause control for a noisy template or destination problem, and make replay tooling respect deduplication and suppression state.

Review the full lifecycle in staging with delayed events, duplicate webhook deliveries, provider errors, user opt-outs between enqueue and send, and worker restarts. Keep a human-readable audit trail of policy decisions without retaining unnecessary message content. The email classification guide covers one common policy boundary; the developer guide hub links to all current patterns.