What CASL actually requires before you send a text

Most teams discover CASL the way you discover a load-bearing wall: by removing it. The rules are not complicated, but they are specific, and the penalties are large enough that guessing is a poor strategy — administrative monetary penalties run up to $10 million per violation for organizations.

Here is the practical version for anyone wiring up SMS to Canadian numbers.

You need consent before the first message, not after

CASL covers commercial electronic messages, and SMS counts. Before you send one to a Canadian number you need consent on record, and it comes in two flavours that behave very differently.

Express consent is someone actively agreeing — a ticked box at checkout, a form submission, a reply of START. It does not expire. It lasts until the person withdraws it.

Implied consent comes from a relationship rather than a decision: someone bought from you, or made an inquiry. It is real consent, but it is on a clock. Under CASL §10(9), implied consent from a transaction expires two years after that transaction. A customer who bought from you in 2023 and never came back is not someone you can text today on that basis.

The failure mode here is quiet. Nothing breaks on the day implied consent expires — you just start sending messages you are no longer permitted to send, and you keep doing it until somebody notices.

Record consent when you get it

Consent you cannot evidence is consent you do not have. Record where it came from at the moment it happens:

curl -X POST https://api.honkio.ca/v1/compliance/consents \
  -H "Authorization: Bearer mk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "phone_number": "+16135550199",
    "consent_type": "express",
    "source_description": "Checkout opt-in checkbox",
    "source_ip": "203.0.113.1"
  }'

The source description matters more than it looks. If a complaint ever lands, "Checkout opt-in checkbox" plus a timestamp and an IP is a defensible record. "The customer agreed" is not.

Let the send fail

The useful part of enforcing this at the API layer is that a send without valid consent does not go out. HonkIO refuses it:

HTTP/1.1 451 Unavailable For Legal Reasons

{
  "code": "NO_CONSENT",
  "message": "Message blocked: no valid CASL consent on record for this recipient.",
  "statusCode": 451
}

451 Unavailable For Legal Reasons is not a joke status code here — it is precisely the situation. You will see it in three shapes: NO_CONSENT when nothing is on record, CONSENT_EXPIRED when implied consent aged out, and OPT_OUT_BLOCKED when the recipient opted out.

A blocked send is a much better outcome than a delivered one you have to explain later. Treat a 451 as information about your data, not an obstacle to route around.

Opt-outs have to actually work

A recipient replying STOP, STOPALL, UNSUBSCRIBE, CANCEL, END or QUIT is withdrawing consent. The law gives you ten business days to honour it. Ten business days is a long time to keep texting someone who told you to stop, so HonkIO processes those keywords within seconds and blocks subsequent sends automatically. START and UNSTOP put them back.

You do not have to build keyword parsing, and more importantly you cannot forget to.

The short version

• Express consent does not expire; implied consent expires two years after the transaction
• Record the source and timestamp when consent is given, not later
• Let sends fail with 451 rather than routing around the check
• Opt-out keywords must take effect immediately, not within ten days
• Keep the records — the evidence is the compliance

None of this is legal advice, and CASL has more surface than one post — identification and unsubscribe requirements in message content, for instance. If you are operating at scale, talk to a lawyer who knows it. But if you build consent tracking in from the start, the hard part is already handled.