Send account-security notifications through the IllyVoIP SMS API

Use the IllyVoIP SMS API to notify a customer about a completed security event in your application, such as a password change. Resolve a trusted notification destination, write a minimal message and track one submission for the committed event. This does not customize IllyVoIP’s own sign-in or security messages.

Use a backend with authorized account API access and keep X-Api-Key out of browser code. The API base is https://api.illyvoip.com. Check HTTP status and the JSON result. Examples below are request templates, not records of completed transactions.

SMS submissions can incur charges. Use the standard IllyVoIP sender or a custom sender approved and available for this account. Recipient eligibility, content review, encoding and current service limits still apply. Store an Idempotency-Key with the exact request before submission; preserve both after an uncertain response.

1. Create the notification only after the event commits

Use your application’s committed security-event ID as the notification’s business identity. A transaction that later rolls back should not produce a message saying a password changed. Persist the event and intended notification together, or use your framework’s established after-commit/outbox approach.

1. Record the event type, affected account and completion time.
2. Create one notification intent for that event and channel.
3. Set a unique constraint so repeated event delivery cannot create duplicate intents.
4. Let a controlled worker perform the SMS submission after the security transaction completes.

The notification must not become the mechanism that performs or confirms the security change. Failure to deliver an informational SMS does not mean the underlying password change failed, and delivery does not prove the account is secure.

2. Select the trusted recipient deliberately

Resolve the recipient from your application’s verified notification settings. For a phone-number change, do not automatically trust the newly entered number as the destination for every security alert. Follow your product’s reviewed policy for the existing verified destination and separately verify the replacement.

Keep the account and destination binding in the saved intent. Before sending, check that notification is still appropriate and that no later event invalidated the purpose. If the trusted destination is unavailable, preserve that outcome and use an already authorized alternative channel where your product supports one. Do not guess a number from caller ID or a public contact search.

3. Write a short message with a safe next step

POST to /api/v1/sms/messages. This illustrative body deliberately contains no password, code, recovery secret or private activity detail:

{
  "from": "IllyVoIP",
  "to": ["+12025550123"],
  "message": "Your Example account password was changed. If this was not you, open the Example app and review account security."
}

Replace the fictional product wording and documentation number before an intended send. Prefer directing the recipient to their known application. If you include a link, use your recognized HTTPS domain and an authenticated security page; do not embed an API key, reset secret or recovery code in the SMS or URL.

Keep lock-screen visibility in mind. A concise description and time may be enough; avoid exposing full email addresses, private device identifiers or precise location. Review the final text and SMS encoding rather than mechanically appending raw event data.

4. Submit and retain the outcome

1. Claim the saved event notification once and store a stable SMS request key.
2. Send the frozen sender, recipient and message from the backend.
3. On acceptance, retain the returned message ID and cost alongside the event reference.
4. Follow delivery with the status endpoint or verified webhook handling.
5. Label a lost response uncertain until reconciled with the same saved request identity.

Rate-limit repeated notifications in your application without silently losing material security events. If you combine several events into a summary, define that policy explicitly and retain which events it covers. Do not run an uncontrolled paid retry loop whenever a delivery report is delayed.

5. Keep notification state separate from security response

Use distinct states for event committed, notification pending, queued, delivered, failed and uncertain. A delivered result is not evidence the customer read the alert or approved the action. Your normal account-recovery and incident-response flow must remain available independently of SMS.

For troubleshooting, retain safe event and message references, HTTP status and timestamps. Avoid putting secrets or full message receipts in ordinary logs. If IllyVoIP requests sender or use-case review, complete that process instead of changing senders to bypass it.

6. Test the events that commonly produce duplicates

Simulate a rolled-back change, a repeated committed event, a changed unverified recipient, a worker restart after acceptance and a delayed delivery webhook. Confirm the first produces no notification and repeats preserve the same intent. Test content with non-ASCII characters and a rejected sender. These local tests establish application behavior; they do not prove handset delivery or the security of the customer’s account.

Related guides

• Send an SMS with the IllyVoIP API and track delivery
• Send queued SMS notifications from Laravel with IllyVoIP
• Send SMS after a Django database transaction with IllyVoIP

Reference

Current instructions and technical reference: IllyVoIP API documentation.

Reviewed 13 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.