PluginBench
Skill
Review
Audit score 70

sms-10dlc-registration

sentdm/sent-plugin

Prepare and validate US A2P 10DLC brand and campaign registration for SMS compliance.

What is sms-10dlc-registration?

This skill handles US A2P SMS registration over 10-digit long codes through Sent's Sender Profiles API. It separates compliance evidence validation from API request construction, manages brand/campaign inheritance, and guides safe workflow from evidence collection through TCR submission and rejection remediation.

  • Validate evidence packets against internal 10DLC compliance schema
  • Generate and validate camelCase Sent campaign API requests
  • Manage brand and campaign inheritance strategies (inherit both, brand only, or own both)
  • Support all 13 TCR use cases with sample message validation
  • Handle low-volume tier classification and volume-based status tracking
  • Provide rejection remediation guidance and TCR status tracking

How to install sms-10dlc-registration

npx skills add https://github.com/sentdm/sent-plugin --skill sms-10dlc-registration
Prerequisites
  • Access to Sent v3 API and valid authentication credentials
  • Python environment for running validation scripts (validate_10dlc_packet.py, validate_campaign_payload.py)
  • Compliance evidence checklist and supporting documentation (privacy policy, terms, opt-in proof)
Claude Code
Cursor
Windsurf
Cline

How to use sms-10dlc-registration

  1. 1.Confirm the traffic is US A2P 10DLC and identify the actual sending business
  2. 2.Decide on brand/campaign inheritance strategy based on your use case
  3. 3.Collect and validate the evidence packet using the internal schema validator
  4. 4.Create or confirm the profile brand via POST /v3/profiles with brand details
  5. 5.Translate evidence into the exact camelCase campaign request structure
  6. 6.Validate the campaign payload locally and test with sandbox: true
  7. 7.Display the payload for confirmation before creating or updating in production
  8. 8.Store profile ID, campaign ID, submittedToTCR status, and raw response for audit

Use cases

Good for
  • Registering account notification campaigns for opted-in customer bases
  • Setting up two-factor authentication and security alert SMS flows
  • Configuring mixed-use campaigns with marketing and transactional messages
  • Remediating TCR rejections with evidence updates and resubmission
  • Validating compliance evidence before submitting to carrier networks
Who it's for
  • SMS platform operators managing US A2P compliance
  • Backend engineers building SMS notification systems
  • Compliance teams preparing TCR registration packages
  • DevOps engineers automating carrier onboarding workflows

sms-10dlc-registration FAQ

What is the difference between the evidence packet and the campaign request?

The evidence packet is an internal compliance document using snake_case and the sent-10dlc-evidence/v1 schema; the campaign request is the exact camelCase API payload sent to Sent's v3 API. They have different validators and schemas.

Can I inherit both brand and campaign?

Yes. Set inherit_tcr_brand: true and inherit_tcr_campaign: true to share an organization brand and campaign. Inherited campaigns are read-only.

What volume threshold determines low-volume tier?

Values below "2000" use the low-volume tier; "2000" and above move to the next tier. Volume is supplied as a numeric string.

How many sample messages do I need per use case?

Each use case accepts 1–5 samples up to 1,024 characters each. Marketing and mixed traffic require at least two samples; other use cases require at least one.

What should I do if my campaign is rejected by TCR?

Review the rejection reason, consult the rejection remediation guide, update your evidence packet and campaign details, validate locally, and resubmit with sandbox: true before production.

Full instructions (SKILL.md)

Source of truth, from sentdm/sent-plugin.


name: sms-10dlc-registration description: 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.

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

BrandCampaignSettings
Inherit bothOrganization brand and campaigninherit_tcr_brand: true, inherit_tcr_campaign: true
Inherit brand, own campaignShared legal brand with tenant-specific trafficbrand true, campaign false
Own bothDedicated tenant/businessboth 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.

python scripts/validate_10dlc_packet.py evidence.json

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.

Sent campaign request

The API request uses exact camelCase and a campaign wrapper:

<!-- sent-campaign-request -->
{
  "campaign": {
    "name": "Acme account notifications",
    "description": "Account and delivery notifications for opted-in customers.",
    "type": "App",
    "useCases": [
      {
        "messagingUseCaseUs": "ACCOUNT_NOTIFICATION",
        "sampleMessages": [
          "Acme Example: Your account preference was updated. Reply STOP to opt out."
        ]
      }
    ],
    "volume": "2000",
    "messageFlow": "Customers opt in in account settings before notifications begin.",
    "privacyPolicyLink": "https://example.com/privacy",
    "termsAndConditionsLink": "https://example.com/terms",
    "optinMessage": "Acme Example: You are subscribed. Reply STOP to opt out.",
    "optoutMessage": "Acme Example: You are unsubscribed and will receive no more messages.",
    "helpMessage": "Acme Example: Visit https://example.com/support for help.",
    "optinKeywords": "START,YES",
    "optoutKeywords": "STOP,UNSUBSCRIBE",
    "helpKeywords": "HELP,INFO"
  },
  "sandbox": true
}

Validate it with:

python scripts/validate_campaign_payload.py campaign.json

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 for classification and references/10dlc-rejection-remediation.md for failures.