# CON-027 — The opt-in URL must land on a page that carries the opt-in

> The page at the submitted opt-in URL must contain the opt-in form itself, not merely mention or link to it.

- **Rule ID:** CON-027
- **Layer:** Consent flow (`CONSENT_FLOW`)
- **Checks:** `opt-in page DOM`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the crawled website or policy page
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** AWS, Bandwidth
- **Applies:** Applies when consent was collected by web form, checkout, account settings, QR code and third party.
- **Canonical URL:** https://ekas.io/rules/10dlc/consent-flow/con-027/

## Why this rule exists

A reviewer opens the URL and expects to see the thing being registered. Landing on a homepage, a marketing page, or a page whose signup lives one click further in reads as evidence that could not be produced, and it is rejected without anyone hunting for the real page. Brands submit the wrong URL constantly because the opt-in is a modal or a footer widget and the page they think of as "the signup page" is the one that advertises it.

## How to fix it

Submit the URL of the page the form is actually on, opening the modal first if that is where it lives and using the deep link if one exists. Done when loading that URL in a fresh browser shows the phone field and the consent control without any further clicks.

## Example of a compliant value

```text
opt_in_url: https://acmecoffee.com/checkout — not https://acmecoffee.com
```

## Common mistakes

- A form that only appears after a delay, a scroll, or an exit-intent trigger is not on the page as far as a crawler is concerned — host a permanent version and register that.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Bandwidth/DCA | `2125` | yes |