首页/法务与合同/sms-10dlc-registration
S

sms-10dlc-registration

by @sentdmv
4.3(120)

此技能用于准备和验证美国 A2P 10DLC 品牌与活动注册,涵盖证据包校验、API 请求构建、沙箱验证及 TCR 状态跟踪。它帮助开发者避免合规错误、减少返工,并确保短信注册流程高效合规,尤其适用于处理继承策略和拒绝原因修复。

10dlca2psmscomplianceregistrationGitHub
安装方式
npx skills add https://github.com/sentdm/sent-plugin --skill sms-10dlc-registration
compare_arrows

Before / After 效果对比

1
使用前

在没有这个技能之前,开发者和合规团队需要手动整理证据、对照API文档构建请求,并反复验证字段格式。由于对继承策略和合规要求理解不深,经常导致注册被拒,需要多次返工,平均耗时很长。

使用后

此技能提供标准化的证据包校验和API请求验证,自动识别继承策略和合规要点,帮助用户在几分钟内完成准确的注册准备,显著减少错误和返工,缩短上线时间。

SKILL.md

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:

{
  "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.

用户评价 (0)

发表评价

效果
易用性
文档
兼容性

暂无评价

统计数据

安装量1.9K
评分4.3 / 5.0
版本
更新日期2026年8月23日
对比案例1 组

用户评分

4.3(120)
5
37%
4
43%
3
13%
2
5%
1
2%

为此 Skill 评分

0.0

兼容平台

🤖claude-code

时间线

创建2026年8月16日
最后更新2026年8月23日
🎁 Agent 知识卡片
调研问卷