sms-10dlc-registration
Prepares and validates Sent US A2P 10DLC brand and campaign registration through Sender Profiles, including inheritance, all campaign use cases, opt-in evidence, sample-message policy, autoresponses, sandbox validation, TCR status, and rejection remediation.
By sentdm · 2,751 installs
npx skills add sentdm/sent-plugin --skill sms-10dlc-registration
Source repository · Upstream listing
SMS 10DLC Registration
Use this skill for US A2P SMS over 10 digit long codes. Separate the compliance evidence packet from the exact Sent API request; they have different schemas and validators.
Current Sent resource model
There is no standalone brand CRUD path in the current v3 API.
Create a dedicated brand inside POST /v3/profiles using brand and inherit tcr brand: false .
List/create campaigns with GET POST /v3/profiles/{profileId}/campaigns .
Update/delete with PUT DELETE /v3/profiles/{profileId}/campaigns/{campaignId} .
Reject guidance that reintroduces a free standing brand path.
Choose inheritance deliberately
Brand Campaign Settings
Inherit both Organization brand and campaign inherit tcr brand: true , inherit tcr campaign: true
Inherit brand, own campaign Shared legal brand with tenant specific traffic brand true, campaign false
Own both Dedicated tenant/business both false and supply brand during profile creation
Inherited campaigns are read only. A profile cannot supply brand while brand inheritance is true.
Two validation layers
Evidence readiness packet
The private packet uses the explicit internal version sent 10dlc evidence/v1 and snake case evidence fields. It is not an API payload.
Collect legal identity, public website/policy links, consent proof, message flow, opt in/opt out/help responses and keywords, use cases, and realistic samples. See [references/10dlc evidence checklist.md](references/10dlc evidence checklist.md).
Sent campaign request
The API request uses exact camelCase and a campaign wrapper:
<! sent campaign request
Validate it with:
API use cases
Support all 13 current values:
MARKETING , ACCOUNT NOTIFICATION , CUSTOMER CARE , FRAUD ALERT , TWO FA , DELIVERY NOTIFICATION , SECURITY ALERT , M2M , MIXED , HIGHER EDUCATION , POLLING VOTING , PUBLIC SERVICE ANNOUNCEMENT , and LOW VOLUME .
Each use case structurally accepts 1–5 samples, each no longer than 1,024 characters. The compliance layer requires at least two samples for marketing and mixed traffic, including low volume mixed. Keep that policy distinction visible instead of pretending OpenAPI requires two for all traffic.
Volume and status
volume is optional and, when supplied, is a numeric string. Values below "2000" use the documented low volume tier; "2000" is the boundary to the next tier.
Campaign responses currently expose statuses SENT CREATED , ACTIVE , and EXPIRED , plus submittedToTCR . Preserve unknown future status strings. Do not confuse a successful Sent record creation with TCR submission or carrier activation.
Safe workflow
1. Confirm this is US A2P 10DLC traffic and the actual sending business is identified.
2. Select brand/campaign inheritance.
3. Validate the versioned evidence packet.
4. Create or confirm the profile brand.
5. Translate evidence into the exact camelCase campaign request.
6. Validate locally and use sandbox: true .
7. Show the payload and obtain confirmation before a real create/update/delete.
8. Store profile ID, campaign ID, submittedToTCR , raw status, and review evidence.
9. Complete the profile with required webHookUrl only after prerequisites are ready.
Never use real consumer data in fixtures or samples. Use [references/tcr use cases.md](references/tcr use cases.md) for classification and [references/10dlc rejection remediation.md](references/10dlc rejection remediation.md) for failures.