INBOUND WEBHOOKS

Events from the outside world become triggers in your panel.

A payment confirmation, a new order, a call status, a release — your providers' webhooks gather at one address. SendNomi verifies the signature and forwards the event cleanly to your own endpoint; anything undelivered queues up and returns with one click. The era of hand-written webhook handlers ends today.

6 sources
payments · CI · telephony · e-commerce · CRM · custom HMAC
HMAC + replay
SHA-256/SHA-1 signatures, timestamp + nonce protection
Dead-letter
an undelivered event queues up and returns with one click
Delivery tester
send a test event, see the response inline
01 / Connect

Six source categories, one receiving address.

You create a receiver in the panel: choose the source type and paste your provider's shared secret. Enter the SendNomi address generated for you in the provider's webhook settings and the connection is done. The most common signature schemes for payments, code hosting, telephony, e-commerce and CRM are built in; a service not on the list connects via a custom HMAC definition with your own secret and header name.

SOURCE CATEGORIES
  • Payments & billing HMAC-SHA256
    Payment success/failure, subscription lifecycle, invoice issuance.
  • Code hosting & CI HMAC-SHA256
    Push, pull request, issue, release.
  • Telephony & SMS HMAC (URL-aware)
    SMS delivery reports (DLR), call status, messaging alerts.
  • E-commerce platforms HMAC-SHA256
    Order creation, customer update, fulfillment.
  • CRM & field tools HMAC or OAuth bearer
    Lead, deal, support ticket, customer lifecycle.
  • Custom HMAC your own secret
    A service not on the list: your own shared secret + header name.
Asking about a specific provider? Support confirms within 1 business day.
02 / Verify

Forged payloads stop at 401; unsigned events never enter.

Every provider has its own HMAC scheme; SendNomi verifies the signature for you. SHA-256 and SHA-1 signatures are supported; the timestamp + nonce check blocks the same request from being replayed. A request that fails verification is rejected with 401, and every event — accepted or rejected — is written to the log. A payload only travels on once its signature passes.

# Send a signed test event — watch the verification live
curl -X POST https://app.sendnomi.com/api/webhooks/inbound/<account-id>/test \
  -H "Content-Type: application/json" \
  -H "X-Signature: sha256=<signature>" \
  -d '{"event":"test","payload":{...}}'

# 200 OK → signature valid, event accepted
# 401    → signature invalid or a replayed request
SHA-256SHA-1timestamp + nonce
03 / Process

A verified event reaches your own endpoint clean.

Headers are normalized, the payload is transformed on request, and the event is forwarded to your own endpoint URL. If your endpoint cannot respond right then, SendNomi retries with 3 attempts + exponential backoff and jitter; each attempt is bound to a 30-second timeout. If the same event ID arrives twice, the 24-hour dedup window makes sure it is processed once — your customer never sees a duplicate email or record.

EVENT PATH · SOURCE TO ENDPOINT
  1. Source event
  2. Signature check
  3. Normalization
  4. Your endpoint
Retries
3 attempts
Backoff
exponential + jitter
Timeout
30 seconds
Dedup window
24 hours — event ID or sha(payload)
If the same event ID arrives twice, it is processed once — no duplicate records.
Three common workflows — an event arrives, the action follows on its own

Payment succeeded → invoice email

  1. The checkout-completed event lands on your SendNomi address
  2. The signature is verified, the event is accepted
  3. An automation sends the transactional email with your invoice template
  4. The customer finds the invoice in their inbox within seconds

New order → welcome series

  1. The order-created event arrives from your e-commerce platform
  2. The contact record is created or updated automatically
  3. A first order adds the contact to the "first_purchase" segment
  4. A 3-email welcome series starts on its own

New release → changelog announcement

  1. Code hosting / CI sends the release event
  2. The release body is rendered from Markdown to HTML
  3. A campaign goes out to the changelog-subscribers segment
  4. One-click unsubscribe (RFC 8058) is included
04 / Monitor

A failed delivery isn't lost: it queues and returns.

The live event feed lists every webhook with its status: accepted, rejected, delivered, retrying. With the delivery tester you send a test event to your endpoint from the panel and see the response inline. An event that fails all attempts drops into the dead-letter queue; once you fix the issue, you resend it with one click. No event disappears silently.

LIVE EVENT FEED · SAMPLE VIEW
  • 14:32:07 payment.checkout_completed 200 · delivered
  • 14:31:52 order.created 200 · delivered
  • 14:31:40 call.status_changed retrying 2/3
  • 14:31:05 release.published dead-letter Send again
  • 14:30:48 unknown.source 401 · invalid signature
Delivery tester: send a test event to your endpoint from the panel, see the response inline.
GET STARTED

Your first send within minutes.

Create your free account — 500 sends per month, forever.