Collect and record opt-in before sending IllyVoIP SMS

If your application sends SMS through IllyVoIP, collect and retain the recipient’s messaging choice before submitting messages that rely on opt-in. Your form and permission database belong to your application; the IllyVoIP SMS API is the sending service. Importing a contact or receiving a delivery receipt does not create permission to message them.

1. Define exactly what the person is choosing

1. Name the business that will send the messages and describe their purpose in plain language.
2. Separate different purposes where a person should be able to choose them independently. A service update and a promotional campaign are not automatically the same choice.
3. Explain the expected frequency and provide a working way to withdraw the choice.
4. Link to the relevant privacy information and decide which messaging rules apply to your audience before launching the form.

For a UK example, the ICO explains consent and the limited existing-customer exception for electronic marketing, including text messages, and requires a usable opt-out. Requirements differ by jurisdiction and message purpose; this technical workflow is not a universal legal compliance determination.

2. Make the form explicit

Use a telephone-number field with a clear country context and a separate, initially unchecked opt-in control. For example, your own application might say: “I want Example Company to text me product offers, up to twice a month. I can unsubscribe using the link in each message.” Replace the business, purpose, frequency and withdrawal method with what you actually provide.

1. Show the notice before the person confirms it, rather than hiding it only in general terms.
2. Validate and normalize the number on your server. Keep enough context to avoid silently changing a national number into a different destination.
3. Validate the form’s anti-forgery controls and rate limits. Do not trust a hidden browser field as proof of consent.
4. Save the user’s explicit choice and its notice version in a server-side transaction. Show confirmation only after persistence succeeds.

Where you verify possession of a number, treat that as a separate check. Entering an OTP can establish access to the number in that flow; it does not silently authorize every future marketing purpose. Do not send the marketing message merely because an OTP was verified.

3. Keep a useful, minimal permission record

• Normalized recipient identity and the applicable business or sending application.
• The specific purpose or preference scope.
• The notice version the person saw, with its retained wording.
• The confirmed choice, timestamp and form/source reference needed to explain it.
• Later withdrawal or renewal events and the current preference revision.

Keep this evidence private and retain only what your documented policy needs. A checkbox value without its wording or scope is difficult to interpret later. Do not store permission only inside a browser session that disappears before the queued job is processed.

4. Check the current choice at dispatch time

1. Before adding a recipient to an SMS job, check the permission and suppression record for that exact purpose.
2. Keep the reviewable sender, recipient and message payload in your own job record. Use the existing IllyVoIP SMS submission contract; do not invent a consent field or a consent-registration endpoint.
3. Immediately before dispatch, check the current preference again and coordinate the check with claiming the job in your database. A choice made yesterday may have changed today.
4. If permission is missing, withdrawn or cannot be read reliably, leave the job unsent for review.
5. For an allowed job, submit through the normal quoted or API sending workflow and retain the returned message reference. Track delivery separately.

Use the web opt-out guide below to implement a working withdrawal link. Do not promise “Reply STOP” unless you have an actual supported inbound channel and a handler that persists that request. An alphanumeric sender or an outgoing SMS capability alone does not provide that workflow.

5. Preserve withdrawals across other workflows

Apply the same preference store to scheduled jobs, manual sends and integrations within the chosen scope. A later CSV import must not clear suppression. Cancel unsent jobs when appropriate, and do not describe an already accepted SMS as recalled: a message in flight can arrive after the withdrawal time.

6. Test before allowing paid submissions

With synthetic recipients and a mocked sender, test an unchecked box, invalid number, failed save, duplicate form submission, changed notice, withdrawal before dispatch and an unavailable permission database. Confirm no SMS is submitted in those cases unless the current documented choice permits it. Test the withdrawal link itself, including repeated requests. Enable real sending only after reviewing the intended recipient and cost.

If a recipient questions a message, use the scoped permission and dispatch timestamps to investigate. Delivery success is evidence of transport, not a replacement for that record.

Related guides

• Add a web opt-out link and suppression checks to an IllyVoIP SMS workflow
• Send IllyVoIP SMS from an authenticated website form
• Send an SMS with the IllyVoIP API and track delivery

Reference

Current instructions and technical reference: ICO: electronic mail marketing (UK).

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