Platform sample specifications must be met where an ISV imposes one

The requirementstatement

Where the campaign is registered through an ISV that publishes its own sample specification, the samples must satisfy it — for HubSpot, exactly two samples, each carrying the business name, opt-out instructions including STOP, a privacy-policy link, and bracketed personalisation.

Severityseverity: BlockingBLOCKINGBreaking this rule gets the submission rejected. There is no partial credit.
When it bitesphase: Gates approvalapprovalGet this wrong and the brand or campaign is refused at registration.
What is checkedobject: campaign.sample[]
Where it liveslayer: Message contentMESSAGE_CONTENT
How Ekas settles itdetectability: DeterministicDETERMINISTIC; Settled in code from the values you submitted. No model involved, no judgement call, same answer every time.
What the fix involvesfailureClass: Fix the fieldRETRY_FIELD; A better value in the form fixes it. Ekas can rewrite it and re-check.
Who requires itauthorities: HubSpot
When it appliesapplicabilityText: Applies when the submission target is HUBSPOT.

Why this rule existsrationale

An ISV sits between the business and TCR and applies its own acceptance rules first, so a submission that would clear every carrier requirement is still rejected at the platform without ever reaching a carrier. HubSpot publishes the strictest sample specification found anywhere — a superset of what any carrier asks — and businesses meet the carrier bar, submit, and are refused by their own tooling with no reference to a carrier rule they can look up. It is worth stating separately because the fix is cheap and the confusion is expensive: nothing is wrong with the campaign, only with the shape of it for one route.

How to fix itremediation

Submit exactly two samples and put all four elements in each: the business name at the front, "Reply STOP to opt out", a link to your public privacy policy, and at least one [bracketed] personalisation token. Done when both samples carry all four — HubSpot checks each sample independently rather than the set as a whole.

A compliant exampleexample

sample1: "Acme Coffee: hi [first name], 20% off all espresso blends this weekend. Privacy: https://acmecoffee.com/privacy Reply STOP to opt out."
sample2: "Acme Coffee: hi [first name], order [order number] is ready for pickup. Privacy: https://acmecoffee.com/privacy Reply STOP to opt out."

Common mistakespitfalls

The privacy policy behind the link has to carry the mobile-information non-sharing statement and the rates disclosure — a link to a generic generated policy satisfies this rule and is then rejected on the policy itself.

Notesnotes

Provider-tagged rather than applied as a superset, and that is the whole point of the tag here: this is one vendor's contract, not a carrier requirement, so imposing it on everyone would fail compliant registrations for not doing something no carrier asks. The check returns UNCLEAR while the submission target is unknown, because "we do not know which platform you are using" is the honest answer and returning a vacuous PASS would hide the requirement from the users who owe it. Source: aws-and-resellers.md section A, HUBSPOT-REG.

Rules you will hit next

6 other rules read campaign.sample[]. Fixing one field to satisfy a single rule is how a resubmission trades one rejection for another, so read these before you change anything.

CMP-SAMPLE-COUNTAt least two sample messages are requiredBlockingBLOCKING CMP-SAMPLE-LENEach sample message must be 20–1024 charactersBlockingBLOCKING MSG-031Sample messages must be in EnglishBlockingBLOCKING MSG-042Every message must identify who is sending itBlockingBLOCKING MSG-171Messages must not harass, intimidate or threaten the recipientBlockingBLOCKING MSG-210A political donation programme may not include gaming-related fundraisingBlockingBLOCKING

All message content rules

MSG-296 is one of 122 message content rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.