notifyId is a string you define and attach to each recipient when sending an SMS. Phonovation echoes it back in every outbound event for that recipient — webhooks and DLRs — so you can match each callback to the right record in your own system without relying on phone numbers.
Where it appears
Rules
- User-defined — you choose the value. Use whatever makes sense for your system: a database ID, an order number, a UUID.
- Per recipient — set independently on each entry in
recipientInfo, so different recipients in the same campaign can carry different identifiers. - Optional — if omitted, webhook and DLR callbacks will carry an empty
NotifyId/SMS-NotifyId. You can still receive callbacks; you just won’t be able to match them automatically. - String only — any string up to a reasonable length. There is no enforced format.
Setting a notifyId
Campaign payload with notifyId
notifyId through every subsequent callback.
Use cases
Order and transaction tracking
Attach an order ID so every delivery callback maps directly to a record in your database — no phone number lookups needed.Order tracking notifyId
SMS-NotifyId=order-10045, you update that order row to sms_delivered = true.
Multi-step user journeys
Use the same identifier across the full send → deliver → reply flow to keep a user’s journey stitched together in your logs.Journey step notifyId
Audit trails and support
Store thenotifyId alongside the send record. If a customer contacts support claiming they never received a message, you can pull the DLR and webhook logs for that ID immediately.
Batch reconciliation
After a large campaign send, usenotifyId values to reconcile delivery status back to your CRM or data warehouse — matching each row by ID rather than by phone number.
Full flow example — appointment reminder
This example traces a single message from send through to a reply, showing wherenotifyId appears at each step.
Scenario: A clinic sends an appointment reminder. The patient can reply CONFIRM or CANCEL.
1. Send the message
Appointment reminder request
2. Webhook fires — message accepted
Phonovation immediately sends a webhook to your endpoint:Appointment webhook payload
8821 as sms_queued.
3. DLR fires — message delivered to handset
Minutes later, once the network confirms delivery:Appointment DLR payload
8821 as sms_delivered.
4. Patient replies — inbound relay fires
Sarah texts backCONFIRM. Your inbound relay receives:
Appointment inbound payload
SMS-NotifyId. When the gateway can link the reply to the original outbound message, this will be populated with appt-8821 — no phone number lookup needed. If it’s empty, fall back to looking up SMS-From (353861234567) in your system to find the associated record.
Full state after each step
Full flow example — e-commerce order notification
Scenario: An online shop notifies a customer their order has shipped. If the customer replies, the shop wants to know which order they’re referring to.1. Send the message
Order notification request
2. Webhook — accepted
Order webhook payload
3. DLR — delivered
Order DLR payload
orders table: sms_delivered_at = 2026-04-09 11:14:22 where id = 10045.
4. Customer replies
Order inbound payload
SMS-NotifyId is populated directly — route straight to your support queue with the order context pre-filled. No phone number lookup needed.
Tips
- Keep
notifyIdvalues unique per send where possible. Reusing the same ID across multiple sends makes it harder to distinguish callbacks. - For inbound replies, check
SMS-NotifyIdfirst. If it’s populated, you have a direct link to the original send. If it’s empty, fall back to looking upSMS-Fromin your records — so it’s worth storingnotifyIdalongside the phone number at send time as a safety net. notifyIdhas no meaning to the Phonovation network — it is purely for your use. The gateway stores and echoes it; nothing else.