Collecting an SMS opt-in is three pieces of work: the wording of the invitation, the capture of the answer, and the record you keep. The rules bear on the first and the third.

[What is express written consent](/explained/compliance/what-is-express-written-consent) carries the regulator's definition. [Which consent model applies to SMS](/explained/sms/which-sms-consent-model-applies) covers which of the three models a destination requires.

## What kind of consent does my programme need?

What you intend to send decides it, not how you intend to collect it.

CTIA's [Messaging Principles and Best Practices](https://api.ctia.org/wp-content/uploads/2023/05/230523-CTIA-Messaging-Principles-and-Best-Practices-FINAL.pdf) sorts business messaging into three kinds of content in Exhibit II, each with its own expectation. Where the person started the conversation:

> If the Consumer initiates the text message exchange and the Non-Consumer only responds with relevant information, then no verbal or written permission is expected.

Where you are marketing:

> The Consumer should give express written permission before a Non-Consumer sends them a text message. Consumers may sign a form, check a box online, or otherwise provide consent to receive promotional text messages.

The same exhibit names the case between them:

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

An appointment reminder that ends with a discount code is a promotional message collected as an informational one. Decide what the programme will send before writing the invitation. Retrofitting written consent onto a list gathered for reminders means collecting it again.

## What does the invitation itself have to carry?

Enough for the person to know what they agree to, on the surface where they agree.

Every surface carries the same content: the programme, who is sending, that messages recur and roughly how often, any fees, how to stop, and where to get help. [The CTIA messaging principles](/explained/compliance/what-are-the-ctia-messaging-principles) covers the list and where its force comes from.

Two points about the surfaces.

- **The act is the person's.** Consent buried in an acceptance of terms of service does not qualify. Express written consent turns on the person signing, so a box you tick for them records nothing.
- **A keyword advert is an invitation.** "Text JOIN to this number" carries the same disclosures as a web form, in the advert rather than in the reply.

Where a destination requires double opt-in, the confirming reply comes from the handset and ties the consent to the device. Bird's `confirm` keyword operation marks that reply and "sends nothing today", so the confirmation message comes from your own handler.

## Where does the record go on Bird?

Into a preference statement, keyed to the person and the channel.

`POST /v1/preferences` records one statement: the handle, the channel, and a `status` of `granted` or `revoked`. Three fields carry the consent record.

- **`consented_at`**, when the person agreed. A grant written over a stored opt-out applies only if this timestamp is later than that opt-out.
- **`source`**, a free-form note stored verbatim, for the form name, campaign or import batch.
- **`coverage`**, which defaults to `non_transactional`, so an opt-out leaves receipts and verification codes flowing.

A write is an upsert on channel, handle, sender scope and topic. Statements are ordered causally rather than by arrival: one dated older than the key's current statement is refused with `applied: false`, and the response carries the statement that survived. An out-of-order import is therefore safe to retry.

Bird also records how each statement was made. A statement from an unsubscribe link, a keyword or a preference page outweighs one asserted through the API or an import, and a person's own opt-out cannot be overridden or deleted through the API. A re-import of an old list cannot resurrect someone who left. [Create a preference](/docs/api/reference/create-preference) carries the full field list.

CTIA section 5.1.2 lists the data to retain alongside the consent. The preference statement records the decision, so that list is the target for what your own systems keep.

## What happens when someone texts START?

An existing opt-out ends. Consent does not begin.

Bird fixes what its built-in keywords do: `stop` unsubscribes the sender, and `start` resubscribes them and confirms it. Both act on the record Bird holds, so `start` reverses an opt-out rather than creating a permission. Someone who texts START having never opted in clears a suppression that was not there.

The keyword layer and the consent layer are therefore separate. Bird keeps opt-outs correct on inbound traffic, per sender and per subscriber; [what is a STOP keyword](/explained/sms/what-is-a-stop-keyword) covers that scope. The first permission comes from you.

## What should I check before the first send?

Four things.

1. **The invitation matches the traffic.** Written consent where any of the content will promote.
2. **The destination's model is the one you built.** Read it on [SMS destinations](/products/sms/destinations).
3. **Each grant carries its `consented_at`.** A list imported without it cannot prove the order of events later.
4. **Your handler answers the confirming reply**, where you run a double opt-in.