A phone number entered at checkout may be intended for delivery updates. Adding that number to a promotional campaign requires permission that covers those messages.

## What permission does my program need?

Promotional messages need permission for promotions. A request for service updates covers that informational purpose.

The [CTIA messaging principles](https://api.ctia.org/wp-content/uploads/2023/05/230523-CTIA-Messaging-Principles-and-Best-Practices-FINAL.pdf) set industry expectations for US business texting. Exhibit II expects written permission for promotions. Informational messages need express permission. A relevant response to a conversation the customer starts needs no additional permission under that guidance.

Adding an offer can change a reminder into a promotion. CTIA gives this example:

> Adding a call-to-action (e.g., a coupon code to an informational text) may place the message in the promotional category.

Choose your content before collecting permission, so the invitation covers the messages you actually send. Apply the destination's legal requirements alongside industry guidance. [Express written consent](/explained/compliance/what-is-express-written-consent) explains the US legal definition.

## What should the invitation tell the person?

Show who will send, what they will send, and how the person can stop it.

CTIA section 5.1.1 calls for the program, sender identity and number, fees, opt-out instructions, help details and applicable terms. Keep those disclosures visible beside the action that records agreement. A keyword advertisement needs disclosures too.

For recurring messages, explain the frequency. Send an enrollment confirmation with opt-out and support details. Section 5.1.2.1 describes that confirmation.

Let the person take the agreeing action themselves. Do not preselect their agreement or hide it inside unrelated terms, because neither establishes an informed choice about your messages.

## What evidence should I retain?

Keep the consent time, the person's identity and number, and the invitation they agreed to.

CTIA section 5.1.2 also names the collection method, campaign and IP address where applicable. Save the wording and the action used to agree. A timestamp alone cannot show whether the person agreed to reminders or promotions.

If your program requires double opt-in, ask the person to confirm from their phone before treating enrollment as complete. [SMS consent models](/explained/sms/which-sms-consent-model-applies) explains that extra step.

## How do I record consent in Bird?

You record the decision through `POST /v1/preferences`. Retain the supporting evidence in your own system.

Set **`channel`** to `sms` and **`handle`** to the phone number with its country code, such as `+15550001234`. Set **`status`** to `granted` or `revoked`.

- **`consented_at`** records when the person agreed. A grant over a stored opt-out needs a later timestamp. It cannot be in the future.
- **`source`** identifies the form, campaign or import batch. It accepts 1 to 255 characters, so use a short reference to your evidence.
- **`coverage`** accepts `non_transactional` or `all`. The default, `non_transactional`, leaves receipts and verification codes outside that preference's scope.
- **`sender_scope`** limits the statement to one sender. Omit it for channel-wide coverage within the workspace.

Bird compares statements for the same channel, handle, sender scope and topic. A topic groups messages under one subscription. The response's **`topic_id`** identifies that group. A `null` value means every topic.

An older statement returns **`applied: false`**, with the surviving statement in **`preference`**. Check that result so an old import does not appear to have restored permission.

A person's own opt-out has stronger protection than an API assertion. You cannot override or delete it through this API, even with a later timestamp. The [preference endpoint](/docs/api/reference/create-preference) documents the write behavior.

## Does a START reply create the initial consent record?

A START reply ends the sender's suppression. It does not replace your initial consent collection.

Bird's `start` operation ends that suppression. It then sends the configured confirmation. A START from someone never suppressed can receive a confirmation without establishing what they originally agreed to.

The **`confirm`** operation recognizes double opt-in replies. It sends no response. Your handler must complete that flow. [STOP keywords](/explained/sms/what-is-a-stop-keyword) explains the separate keyword and suppression behavior.

## What should I check before sending?

Send only when the invitation, consent evidence and implemented flow agree.

1. Match the permission to the actual message content.
2. Apply the [destination's consent model](/products/sms/destinations).
3. Retain the invitation and consent time, and check Bird's preference-write result.
4. Complete the confirming exchange if your program requires double opt-in.

## Related resources

- [SMS compliance](/products/sms/compliance) (product)
- [Opt-outs and keywords](/docs/guides/sms/opt-outs-and-keywords) (docs)
- [Operate messaging reliably](/learn/paths/reliability) (course)

[Get an implementation brief](/learn/workspace?topic=consent)