Sinch Build for Codex

View saved version →

---
name: sinch-10dlc
description: Registers US 10DLC brands and campaigns with Sinch for A2P SMS messaging. Use when the user needs to register a brand, create a 10DLC campaign, check registration status, troubleshoot a 10DLC rejection, fix an EIN mismatch, upgrade from simplified to full registration, or qualify a campaign for US SMS sending on 10-digit long codes. Do NOT use for non-US messaging or toll-free/short code registration.
metadata:
  author: Sinch
  version: 1.3.0
  category: Numbers
  tags: 10dlc, sms, a2p, brand-registration, campaign-registration, us-messaging, brand, campaign, tcr, registration, a2p-sms
  uses:
    - sinch-authentication
---

# Sinch 10DLC Registration

## Overview

10DLC (10-Digit Long Code) is the required US registration system for Application-to-Person (A2P) SMS on standard 10-digit phone numbers. You must register a **brand** (the sending company) and a **campaign** (the messaging use case) with The Campaign Registry (TCR) via Sinch before sending any US A2P SMS.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block the work:

1. **Goal** — register a brand, register a campaign, check status, or troubleshoot a rejection?
2. **Brand ID?** — if the user already has one, skip to Step 3 (qualify) or Step 4 (campaign).
3. **Registration type** — `SIMPLIFIED` (faster, lowe

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: sinch-authentication
description: Configures Sinch API credentials and authentication. Use when setting up OAuth2, Basic auth, application signing, or API keys for any Sinch product including Conversation API, Voice, Verification, Numbers, Fax, and Mailgun. Also use when troubleshooting 401 Unauthorized, 403 Forbidden, invalid signature, or credential errors against any Sinch API. For SDKs usage, see sinch-sdks.
metadata:
  author: Sinch
  version: 1.3.0
  category: Core
  tags: authentication, oauth2, basic-auth, api-keys, credentials
---

# Sinch Authentication

Cross-cutting skill that covers credential setup and authentication for all Sinch APIs. Determines the correct auth model, provides curl examples, SDK init code, and troubleshooting for common auth errors.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

If the user hasn't specified which Sinch product they're integrating, ask first — the auth model depends on the product. Use the decision table in Step 1 to route to the correct credentials.

## Source of Truth — what to load, and what is authoritative

This skill has two kinds of content with UNEQUAL reliability. Follow this precedence:

1. **Canonical docs at `developers.sinch.com` (AUTHORITATIVE).** The `.md` doc links in
   this skill are the single source of truth for exact request/response schemas, field
   names and nesting, enum values, signature/auth schemes, and limits. Before writing
   code that constructs a payload, verif

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-cli
description: "Terminal commands for the Sinch CLI (`sinch`, npm `@sinch/cli`). Use whenever the user runs or asks about a `sinch` command: login, Functions init/dev/deploy/logs/status, phone numbers and porting, sending SMS/WhatsApp/RCS, placing calls and configuring voice services, fax, SIP trunks, secrets and templates. Runtime code is covered by sinch-functions-node and sinch-functions-dotnet."
metadata:
  author: Sinch
  version: 1.2.0
  category: Functions
  tags: cli, functions, serverless, voice, numbers, conversation, fax, sip, secrets, deploy
  uses:
    - sinch-authentication
    - sinch-functions
    - sinch-functions-node
    - sinch-functions-dotnet
---

# Sinch CLI

## Overview

Sinch Functions and the CLI are in beta: free during the beta period, and commands may change before general availability.

The Sinch CLI (`@sinch/cli`, binary: `sinch`) is a unified command-line tool for the entire Sinch platform. It manages Sinch Functions (serverless), Voice applications and outbound calls, phone Numbers, Conversation messaging (SMS/WhatsApp/RCS and other channels), Fax, Elastic SIP Trunking, secrets stored in the OS keychain, and multi-project configuration profiles.

**Related skills:**
- `sinch-functions` — platform overview, runtime choice, deployment concepts
- `sinch-functions-node` — Node.js runtime code (`function.ts`, `onCall`, the injected `CommandBuilder`, etc.)
- `sinch-functions-dotnet` — C# runtime code (`SinchVoiceController`, `CommandBuilder`, etc.)
- Voice API v2 is covered by the `sinch-voice-api-v2` skill; load it for the REST contract, SVAML v2 commands, and service configuration.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delive

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: sinch-conversation-api
description: "Sends and receives omnichannel messages via the Sinch Conversation API across SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger, Instagram, Telegram, KakaoTalk, LINE, and WeChat. Covers the API layer: apps, contacts, conversations, processing modes, message types, webhooks and callbacks, templates, batch sending, channel fallback, and transcoding. Use when building or modifying a Sinch messaging integration, handling inbound messages or delivery receipts via webhooks, sending multi-channel or batch messages, or managing Conversation API apps, contacts, and webhooks. For channel-specific guidance, use the sinch-sms, sinch-mms, sinch-rcs, or sinch-whatsapp skills."
metadata:
  author: Sinch
  version: 2.1.0
  category: Messaging
  tags: conversation, messaging, sms, whatsapp, rcs, mms, viber, facebook-messenger, instagram, telegram, kakaotalk, line, wechat, webhooks, callbacks, inbound, templates
  uses:
    - sinch-authentication
    - sinch-sdks
---

# Sinch Conversation API

## Overview

One unified API to send and receive messages across SMS, WhatsApp, RCS, MMS, Viber Business, Facebook Messenger, Instagram, Telegram, KakaoTalk, LINE, and WeChat. The API transcodes between a generic message format and channel-specific formats automatically. This skill covers the API layer — apps, contacts, conversations, messages, webhooks, templates, and batch sending. Channel-specific guidance (sender IDs, encoding, templates, media limits) lives in the dedicated channel skills: `sinch-sms`, `sinch-mms`, `sinch-rcs`, `sinch-whatsapp`. Load only the skill(s) for the channel(s) the user is working with — never load a channel skill for a channel the task doesn't touch.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 23 — file references are metadata, not package contents.

View saved version →

---
name: sinch-elastic-sip-trunking
description: Provisions SIP trunks, endpoints, ACLs, credential lists, and phone numbers via the Sinch Elastic SIP Trunking REST API. Use when the user needs SIP connectivity, trunk provisioning, inbound/outbound PSTN voice routing, PBX integration, or SIP-to-PSTN bridging.
metadata:
  author: Sinch
  version: 1.2.1
  category: Voice
  tags: sip, trunking, est, pstn, voice, pbx, inbound, outbound
  uses:
    - sinch-authentication
    - sinch-sdks
---

# Sinch Elastic SIP Trunking API

## Overview

The Sinch Elastic SIP Trunking (EST) API lets you programmatically provision SIP trunks and route voice traffic between customer infrastructure and the PSTN. The core workflow is: create a trunk, authorize it (ACL or credentials), attach endpoints, assign phone numbers.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block implementation:

1. **Direction** — inbound (receive calls from PSTN), outbound (send calls to PSTN), or both?
2. **Auth method for the trunk** (if outbound or both) — ACL-based (static IPs) or Credential-based (digest auth / dynamic IPs)?
3. **Endpoint type** (if inbound or both) — Static endpoint (fixed IP/port) or Registered endpoint (SIP UA registers dynamically)?
4. **Approach** — do not ask. Default to the official Sinch SDK for the resolved language;

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: sinch-fax-api
description: Send and receive faxes programmatically with Sinch Fax API. Use when building fax workflows, fax-to-email delivery, sending PDFs by fax, checking fax status, managing fax services, configuring cover pages, receiving fax webhooks, or integrating fax into healthcare, legal, or financial applications.
metadata:
  author: Sinch
  version: 1.2.0
  category: Voice
  tags: fax, pdf, fax-to-email, webhooks, healthcare, legal
  uses:
    - sinch-authentication
    - sinch-sdks
---

# Sinch Fax API

## Overview

The Sinch Fax API lets you send and receive faxes programmatically. It supports multiple file formats, webhooks for incoming faxes, fax-to-email delivery, and automatic retries. Used for healthcare, legal, financial, and government applications where fax remains a required communication channel.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block implementation:

1. **Use case** — sending, receiving, fax-to-email, or managing services?
2. **Approach** — do not ask. Default to the official Sinch SDK for the resolved language; use direct API calls (curl, `fetch`, `requests`) only when the request or an existing dependency already chooses them, or no official SDK covers the language or operation. State the chosen approach.
3. **Language** — for SDK: Node.js (preview) or .N

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-functions
description: "Sinch Functions, the beta serverless platform for voice, SMS and conversation apps. Use for platform questions: what it is, how deployment works, choosing Node.js or C#, install and auth, FunctionContext, handlers, the Voice v2 call lifecycle and `call.*` events, voice services and `VOICE_SERVICE_ID`, and SVAML. Runtime code lives in sinch-functions-node and sinch-functions-dotnet."
metadata:
  author: Sinch
  version: 1.2.0
  category: Functions
  tags: functions, serverless, voice, conversation, ivr, svaml, runtime, nodejs, csharp
  uses:
    - sinch-authentication
    - sinch-functions-node
    - sinch-functions-dotnet
    - sinch-voice-api-v2
    - sinch-conversation-api
    - sinch-sdks
---

# Sinch Functions

## Overview

Sinch Functions is in beta: free during the beta period, and the API may change before general availability. Sinch API usage (Voice, Conversation, Numbers) is billed as usual.

Sinch Functions is a serverless platform for voice, SMS, and conversation applications. You write a function, deploy it with the CLI, and Sinch routes callbacks and webhooks to it.

Functions are the compute layer between Sinch's telephony network and your business logic. A call comes in, Sinch invokes your function with an event, and your function returns call commands or a webhook response.

Voice API v2 is what a new function is written against. The unversioned name always means the current API: `context.voice` and `Context.Voice` are v2. The v2 sections below lead this skill because developers.sinch.com does not yet have a Functions-on-v2 page. Existing Voice v1 functions keep running unchanged; see [Voice v1 callbacks](https://developers.sinch.com/docs/functions/functions/concepts/voice-callbacks.md).

**Related skills for deeper guidance:**
- `sinch-cli` — CLI commands for the full Sinch platform (Functions, Voice, Numbers, Conversation, Fax, SIP)
- `sinch-functions-node` — Node.js/TypeScript runtime API
- `sinch-functions-dotnet` — C#/.NET runtime API
- Voice API v2 is covered by the `sinch-voice-api-v2` skill; load it for the REST contract, SVAML v2 commands, and service configuration.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before fa

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-functions-dotnet
description: "Write C#/.NET Sinch Functions with the `Sinch.Functions.Runtime` NuGet package. Use when writing or editing a function controller: answering and controlling calls with Voice API v2, IVR menus, placing, bridging or transferring calls, realtime AI voice agents, SMS/WhatsApp/RCS webhooks, custom HTTP endpoints, dependency injection, cache/storage/database and authorization. Run and deploy with the sinch-cli skill."
metadata:
  author: Sinch
  version: 1.2.0
  category: Functions
  tags: functions, csharp, dotnet, aspnet, serverless, voice, svaml, ivr, voice-agent, conversation-webhooks, runtime
  uses:
    - sinch-authentication
    - sinch-functions
    - sinch-conversation-api
    - sinch-voice-api-v2
    - sinch-sdks
    - sinch-sms
    - sinch-numbers-api
---

# Sinch Functions — C#/.NET Runtime

## Overview

Sinch Functions is in beta: free during the beta period, and the API may change before general availability.

Package: `Sinch.Functions.Runtime` (NuGet). Write C# functions using ASP.NET controller patterns with dependency injection, answering phone calls, handling conversation webhooks, and serving custom HTTP endpoints.

This skill describes `Sinch.Functions.Runtime` 0.3.17 and later, where a voice handler is an `OnIncoming(Call, CommandBuilder)` override. Earlier releases used a `Handlers` property returning `CallHandlers`. That surface was removed, so do not generate it. Voice API v2 is what `Context.Voice` is and what a new function is written against. The unversioned name always means the current API: `Context.Voice` is `SinchFunctions.Voice.V2.Client`. The v2 sections below lead this skill because developers.sinch.com does not yet have a Functions-on-v2 page. Existing Voice v1 controllers keep running unchanged; see [Voice v1 callbacks](https://developers.sinch.com/docs/functions/functions/concepts/voice-callbacks.md).

**Related skills:**

- `sinch-functions` — platform overview, concepts, runtime choice
- `sinch-cli` — terminal commands (`sinch functions dev`, `sinch functions deploy`, etc.)
- Voice API v2 is covered by the `sinch-voice-api-v2` skill; load it for the REST contract, SVAML v2 commands, and service configuration.
- `sinch-functions-node` — the same concepts in Node.js/TypeScript

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched do

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: sinch-functions-node
description: "Write Node.js/TypeScript Sinch Functions with `@sinch/functions-runtime`. Use when writing or editing `function.ts`: answering and controlling calls with Voice API v2, IVR menus, placing or bridging calls, SMS/WhatsApp/RCS webhooks, custom HTTP endpoints, cache/storage/database, auth and `setup()` hooks. Run and deploy with the sinch-cli skill."
metadata:
  author: Sinch
  version: 1.2.0
  category: Functions
  tags: functions, nodejs, typescript, serverless, voice, svaml, ivr, conversation-webhooks, runtime
  uses:
    - sinch-authentication
    - sinch-functions
    - sinch-conversation-api
    - sinch-voice-api-v2
    - sinch-sdks
    - sinch-sms
    - sinch-numbers-api
---

# Sinch Functions — Node.js Runtime

## Overview

Sinch Functions is in beta: free during the beta period, and the API may change before general availability.

Package: `@sinch/functions-runtime` (npm). Write TypeScript/JavaScript functions that answer phone calls, handle conversation webhooks, and serve custom HTTP endpoints.

Voice API v2 is what `context.voice` is and what a new function is written against. The unversioned name always means the current API: `context.voice` is v2. The v2 sections below lead this skill because developers.sinch.com does not yet have a Functions-on-v2 page. Existing Voice v1 functions keep running unchanged; see [Voice v1 callbacks](https://developers.sinch.com/docs/functions/functions/concepts/voice-callbacks.md).

**Related skills:**

- `sinch-functions` — platform overview, concepts, runtime choice
- `sinch-cli` — terminal commands (`sinch functions dev`, `sinch functions deploy`, etc.)
- Voice API v2 is covered by the `sinch-voice-api-v2` skill; load it for the REST contract, SVAML v2 commands, and service configuration.
- `sinch-functions-dotnet` — the same concepts in C#

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: sinch-help
description: Show an overview of the Sinch Build product guides and documentation search available in this plugin
---

# Sinch Build for Codex

Display a concise overview of what this plugin provides. Output the overview directly; do not write scripts or files.

## Instructions

Display the following structure directly:

1. **Documentation search (Sinch Docs MCP)**
   - Search and read Sinch developer documentation. No credentials required.

2. **Messaging**
   - sinch-conversation-api - Omnichannel messaging across SMS, WhatsApp, RCS, MMS, Viber, and Messenger
   - sinch-sms - SMS channel: sender IDs, encoding, and opt-out handling
   - sinch-mms - MMS channel: media types, size limits, and transcoding
   - sinch-rcs - RCS channel: rich cards, carousels, and suggested replies
   - sinch-whatsapp - WhatsApp channel: templates and the 24-hour service window
   - sinch-in-app-calling - In-app voice and video SDK for Android, iOS, and JavaScript

3. **Voice and verification**
   - sinch-voice-api - Calls, text-to-speech, IVR menus, DTMF input, and conferencing
   - sinch-voice-api-v2 - Voice API v2 (public preview) calls, webhooks, and SVAML v2
   - sinch-verification-api - SMS, flashcall, phone call, data, and WhatsApp verification

4. **Phone numbers**
   - sinch-numbers-api - Search, rent, manage, and release numbers
   - sinch-number-order-api - Number ordering with KYC compliance
   - sinch-porting-api - Port numbers from other carriers into Sinch
   - sinch-imported-numbers-hosting-orders - Import and text-enable non-Sinch numbers for SMS
   - sinch-number-lookup-api - Carrier, line type, porting status, and SIM swap checks
   - sinch-10dlc - US 10DLC brand and campaign registration
   - sinch-elastic-sip-trunking - SIP trunks, endpoints, ACLs, and credential lists
   - sinch-provisioning-api - WhatsApp and RCS sender provisioning

5. **Fax**
   - sinch-fax-api - Send and receive faxes programmatically

6. **Email**
   - sinch-mailgun - Send, receive, and track email
   - sinch-mailgun-validate - Email verification and list hygiene
   - sinch-mailgun-inspect - Pre-send email quality and accessibility checks
   - sinch-mailgun-optimize - Inbox placement and deliverability monitoring

7. **Serverless and CLI**
   - sinch-functions - Sinch Functions serverless platform (beta)
   - sinch-functions-node - Write Sinch Functions in Node.js/TypeScript
   - sinch-functions-dotnet - Write Sinch Functions in C#/.NET
   - sinch-cli - Sinch CLI commands

8. **SDKs and authentication**
   - sinch-sdks - SDK installation and client initialization for Node.js, Python, Java, and .NET
   - sinch-authentication - OAuth2, Basic auth, application signing, and API keys

**Note**: Documentation search needs no credentials. Some product guides include optional scripts that call live Sinch APIs (for example sending a test SMS or managing webhooks); they use your own Sinch credentials from environment variables, run only with your approval, and may incur charges. Create a Sinch account at https://dashboard.sinch.com/?utm_source=Codex&utm_medium=sinch_codex_plugin to start building.

View saved version →

---
name: sinch-imported-numbers-hosting-orders
description: Import, host, qualify, and text-enable phone numbers for Sinch SMS using the Imported Numbers and Hosting Orders API. Use when importing non-Sinch numbers as DCA, creating hosting orders, qualifying numbers for text-enablement, managing LOA workflows, or checking hosting order status.
metadata:
  author: Sinch
  version: 1.2.0
  category: Numbers
  tags: imported-numbers, hosting-orders, text-enablement, dca, loa
  uses:
    - sinch-authentication
---

# Sinch Imported Numbers & Hosting Orders

## Overview

The Imported Numbers and Hosting Orders API imports non-Sinch phone numbers for use with Sinch SMS without porting. It manages the lifecycle from qualification through text-enablement, including LOA generation and carrier OSR updates.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block the work:

1. **Goal** — import a number (single or bulk), qualify numbers for text-enablement, text-enable qualified numbers, or check status of an existing order?
2. **LOA type** (if text-enabling) — direct Sinch customer, reseller, or blanket LOA?
3. **Number type** (if text-enabling) — Standard or Toll-Free?
4. **Language** — any language, or curl. This API is REST-only; there is no SDK wrapper.

Refer to the API reference linked in Links for request/respo

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: sinch-in-app-calling
description: Integrate Sinch In-App Voice and Video SDK for real-time calling in Android, iOS, or JavaScript apps. Use when the user mentions In-App Calling, VoIP integration, WebRTC with Sinch, app-to-phone calling, video calling, or building voice/video features in a mobile or web app.
metadata:
  author: Sinch
  version: 1.2.0
  category: Voice & Video
  tags: in-app-calling, voip, webrtc, voice, video, android, ios, javascript
  uses:
    - sinch-authentication
---

# Sinch In-App Calling

## Overview
Real-time voice and video SDK for **Android**, **iOS**, and **JavaScript (Web)**. Connects to Sinch's cloud for signaling and routing.

### Supported call types
- App-to-App (VoIP/WebRTC between users)
- App-to-Phone (call PSTN numbers)
- App-to-SIP (connect to PBXs, contact centers)
- App-to-Conference (multi-party calls)
- Phone-to-App / SIP-to-App (inbound calls)

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

### Prerequisites
The user needs a Sinch account with an application key and secret from the [Sinch Build Dashboard](https://dashboard.sinch.com/voice/apps). See `sinch-authentication` for credential setup — In-App Calling uses **application-scoped** auth (Application Key + Application Secret).

### Integration workflow

1. **Detect the platform** from the user's project (language, build system, framework):
   - Android (Kotlin/Java, Gradle) → Read `references/android.md`
   - iOS (Swift/ObjC, Xcode) → Read `refe

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 11 — file references are metadata, not package contents.

View saved version →

---
name: sinch-mailgun
description: Sends, receives, and tracks email via the Mailgun (Sinch) API. Use when the user wants to send email, manage domains, configure webhooks, query email events/logs, manage templates, handle suppressions (bounces, unsubscribes, complaints), set up inbound routes, manage mailing lists, DKIM keys, or IP warmup using Mailgun.
metadata:
  author: Sinch
  version: 1.2.0
  category: Email
  tags: email, mailgun, smtp, webhooks, templates, domains, suppressions
  uses:
    - sinch-authentication
---

# Mailgun Email API

## Overview

Mailgun (by Sinch) provides REST API and SMTP relay for transactional and bulk email — sending, receiving, tracking, and suppression management.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block implementation:

1. **Region** — US or EU. Region determines the base URL and cannot be changed after domain creation.
2. **Approach** — do not ask. Default to the official Sinch SDK for the resolved language; use direct API calls (curl, `fetch`, `requests`) only when the request or an existing dependency already chooses them, or no official SDK covers the language or operation. State the chosen approach.
3. **Language** — for SDK: Node.js (`mailgun.js`). For direct API: any language, or curl. Other languages must use direct HTTP — there is no first-party

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: sinch-mailgun-inspect
description: Checks email quality before sending via Mailgun Inspect API. Use when previewing emails across clients, checking accessibility (WCAG), validating links, validating images, or analyzing email HTML/CSS compatibility.
metadata:
  author: Sinch
  version: 1.2.0
  category: Email
  tags: email, mailgun, inspect, accessibility, links, images, previews, qa
  uses:
    - sinch-authentication
---

# Mailgun Inspect

## Overview

Mailgun Inspect (by Sinch) is an email pre-send quality control API. Five capabilities:

| Capability | Base Path | Input |
|------------|-----------|-------|
| Accessibility | `/v1/inspect/accessibility` | `html` + `encoded` |
| Link Validation | `/v1/inspect/links` | `links` URL array (or `/html-validate` for HTML) |
| Image Validation | `/v1/inspect/images` | `links` URL array (or `/html-validate` / `/upload`) |
| Code Analysis | `/v1/inspect/analyze` | `html` (no `encoded` field) |
| Email Previews | `/v1/preview/tests` (V1) / `/v2/preview/tests` (V2) | varies |

*(Summary only — confirm exact names/encoding/enums against the authoritative [API Reference (Markdown)](https://documentation.mailgun.com/docs/inspect/api-reference/openapi-final.md) doc before implementing.)*

For full endpoint tables and request schemas, see [references/api-endpoints.md](references/api-endpoints.md).

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turn

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: sinch-mailgun-optimize
description: Monitors email deliverability via Mailgun Optimize (InboxReady) API. Use when the user wants to test inbox placement with seed lists, monitor IP or domain blocklists, track spam traps, check email health scores, review DMARC reports, or pull Google Postmaster or Microsoft SNDS data. Also use when emails are going to spam, sender reputation is dropping, inbox rate is declining, a domain needs warmup monitoring, an IP needs blocklist removal, or the user wants to set up email deliverability monitoring.
metadata:
  author: Sinch
  version: 1.2.0
  category: Email
  tags: email, mailgun, deliverability, inbox-placement, blocklist, dmarc, spam-traps
  uses:
    - sinch-authentication
---

# Mailgun Optimize (InboxReady)

## Overview

Mailgun Optimize (by Sinch), formerly InboxReady, is a deliverability suite: inbox placement testing via seed lists, IP and domain blocklist monitoring, spam trap tracking, email health scoring, DMARC reporting, Google Postmaster Tools integration, and Microsoft SNDS data.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block the work:

1. **Region** — US or EU? Region determines the base URL.
2. **Language** — any language, or curl. This API is REST-only; there is no SDK wrapper.
3. Before generating code, check for existing `.env` fil

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: sinch-mailgun-validate
description: Build with Mailgun Validate API for email verification and list hygiene. Use when validating email addresses, checking email deliverability, running bulk validation jobs, previewing list health, or cleaning an email list.
metadata:
  author: Sinch
  version: 1.2.0
  category: Email
  tags: email, mailgun, validation, verification, list-hygiene, bulk-validation
  uses:
    - sinch-authentication
---

# Mailgun Validate

## Overview

Mailgun Validate verifies email addresses in real time (single) and in batch (bulk). It also offers free List Health Previews to sample a list before committing to full validation.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block implementation:

1. **Approach** — do not ask. Default to the official Sinch SDK for the resolved language; use direct API calls (curl, `fetch`, `requests`) only when the request or an existing dependency already chooses them, or no official SDK covers the language or operation. State the chosen approach.
2. **Language** — for SDK: Node.js, Python, Java, PHP, Ruby, or Go. For direct API: any language, or curl.

When using the **SDK**, refer to the relevant SDK reference linked in Links.

When using **direct API calls**, refer to the API reference linked in Links for request/response schemas.

**Security

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-mms
description: "Sends MMS multimedia messages (images, video, audio, PDFs, vCards) via the MMS channel of the Sinch Conversation API. Available in the United States, Canada, and Australia only. Covers supported media types, file size limits, MMS channel properties, and transcoding behavior. Use when sending an MMS or picture message, sending media to US/CA/AU numbers over MMS, or debugging MMS media rejection and size issues."
metadata:
  author: Sinch
  version: 1.2.0
  category: Messaging
  tags: mms, media-message, picture-message, multimedia, image, video, vcard, toll-free, conversation
  uses:
    - sinch-conversation-api
    - sinch-authentication
    - sinch-sdks
---

# Sinch MMS

## Overview

MMS (Multimedia Messaging Service) extends SMS with support for images, video, audio, PDFs and other media. Available in the **United States, Canada, and Australia** only. This skill covers the MMS channel of the Sinch Conversation API: media types, size limits, channel properties, and transcoding behavior.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Apply the shared evidence tiers. Fetch the exact canonical operation, schema, or security page before emitting Tier B details; record one source per coherent contract in the evidence ledger. If the fetch fails, follow the shared fail-closed rule instead of substituting bundled content.

This skill covers the **MMS channel** of the Sinch Conversation API and is self-contained for sending MM

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-number-lookup-api
description: Looks up phone number details via Sinch Number Lookup API. Use when checking carrier, line type, porting status, SIM swap, VoIP detection, or reassigned number detection (RND) for fraud prevention or routing decisions.
metadata:
  author: Sinch
  version: 1.2.0
  category: Numbers
  tags: number-lookup, carrier, line-type, sim-swap, voip-detection, fraud-prevention
  uses:
    - sinch-authentication
    - sinch-sdks
---

# Sinch Number Lookup API

## Overview

Queries phone numbers for carrier, line type, porting, SIM swap, VoIP detection, and reassigned number detection. Used for fraud prevention, routing, and data enrichment. One number per request — no batch endpoint.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block implementation:

1. **Approach** — do not ask. Default to the official Sinch SDK for the resolved language; use direct API calls (curl, `fetch`, `requests`) only when the request or an existing dependency already chooses them, or no official SDK covers the language or operation. State the chosen approach.
2. **Language** — for SDK: Node.js or Python (partial). For direct API: any language, or curl. Java and .NET must use direct HTTP — there is no SDK wrapper.

When using the **SDK**, refer to the `sinch-sdks` skill for installation and clie

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-number-order-api
description: Guides the multi-step Number Order workflow for purchasing phone numbers with KYC compliance via the Sinch Numbers API. Use when buying, ordering, provisioning, or activating Sinch numbers in countries that require KYC registration, regulatory compliance, or identity verification. Triggers on "number order", "KYC", "number registration", "phone number purchase", or "number provisioning".
metadata:
  author: Sinch
  version: 1.2.0
  category: Numbers
  tags: number-order, kyc, phone-number, purchase, provisioning, registration
  uses:
    - sinch-authentication
---

# Number Order API

## Overview

Order phone numbers with KYC compliance through a guided multi-step workflow. Required in countries where number purchases need identity verification.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block the work:

1. **Country** — ISO 3166-1 alpha-2 region code (e.g. `AU`, `DE`, `BR`).
2. **Number type** — `MOBILE`, `LOCAL`, or `TOLL_FREE`. *(Summary only — confirm exact names/encoding/enums against the authoritative [Number Order API Reference](https://developers.sinch.com/docs/numbers/api-reference/numbers/number-order.md) doc before implementing.)*
3. **Specific number or quantity?** — E.164 phone number, or quantity + criteria.
4. **SMS or Voice?** — SMS needs `

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-numbers-api
description: "Search, manage, and release phone numbers with the Sinch Numbers API, and route new purchases to the Number Order API. Use when listing active numbers, searching available numbers, releasing numbers, updating number configuration (SMS/voice/callback), managing emergency addresses, checking available regions, or maintaining legacy rent integrations."
metadata:
  author: Sinch
  version: 1.3.0
  category: Numbers
  tags: numbers, phone-numbers, rent, release, search, sms, voice, configuration
  uses:
    - sinch-authentication
    - sinch-sdks
---

# Sinch Numbers API

## Overview

The Numbers API lets you search, activate, manage, and release phone numbers — the prerequisite for SMS, Voice, and Conversation APIs.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Infer the language and approach from the request and workspace instead of asking:

- **Default to the official SDK** (Node.js, Python, Java, or .NET) for the detected language. Use `sinch-sdks` for installation and client initialization, then the bundled language references and SDK reference linked in Links.
- **Use direct HTTP calls** only when the user asks for them, the workspace has no SDK-supported language, or the SDK does not cover the operation. Use the Numbers API Reference linked in Links for request/response schemas.
- Ask one combined question only if a true blocker remains (for example, no language can be inferred at all).

**Buying numbers:** 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: sinch-porting-api
description: "Port phone numbers from other carriers into Sinch with the Porting API. Automates port-in order creation, portability checks, order tracking, on-demand activation, and webhook notifications. Use when porting numbers, checking portability, creating port-in orders, tracking port status, activating ported numbers, uploading LOA documents, or configuring porting defaults."
metadata:
  author: Sinch
  version: 1.2.0
  category: Numbers
  tags: porting, port-in, number-transfer, carrier, portability, loa, foc, activation
  uses:
    - sinch-authentication
---

# Sinch Porting API

## Overview

The Porting API automates port-in operations — transferring phone numbers from another carrier into Sinch. It supports portability checks, order creation and management, document uploads, on-demand activation, and webhook notifications for status updates. Currently supports North American (US/CA) numbers only.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block the work:

1. **Use case** — portability check, create order, track order, or activate numbers?
2. **Activation mode** (only for create order) — Automatic (on `desiredPortDate`) or on-demand (`onDemandActivation: true`)?
3. **Language** — any language, or curl. The `@sinch/sdk-core` Node.js SDK does not currently have dedi

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-provisioning-api
description: Provisions and manages channel resources for Conversation API projects, including WhatsApp accounts/senders/templates, RCS senders, KakaoTalk senders/templates, webhooks, and bundles. Use when the user asks to onboard channels, configure provisioning webhooks, manage templates, orchestrate multi-service bundles, or automate channel setup.
metadata:
  author: Sinch
  version: 1.2.0
  category: Messaging
  tags: provisioning, whatsapp, rcs, kakaotalk, channels, templates, bundles
  uses:
    - sinch-authentication
---

# Sinch Provisioning API

## Overview

Use this skill for Conversation API channel provisioning. Canonical reference fetched 2026-08-19: Provisioning API v1.2.100.
Prefer deterministic flows: confirm context, choose endpoint family, execute minimal calls, verify state.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block the work:

1. **Project ID** — confirm `projectId`.
2. **Microservice scope** — each is a separate REST service: WhatsApp, RCS, KakaoTalk, Conversation, Webhooks, or Bundles. Endpoint families:
   - WhatsApp account/senders/templates/flows/solutions: `/v1/projects/{projectId}/whatsapp/...`
   - RCS: `/v1/projects/{projectId}/rcs/...`
   - KakaoTalk: `/v1/projects/{projectId}/kakaotalk/...`
   - Conversation (channel info): `/v1/pr

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-rcs
description: "Sends RCS (Rich Communication Services) messages via the RCS channel of the Sinch Conversation API — rich cards, carousels, suggested replies and actions, media, location, and calendar actions, with automatic SMS fallback. Use when sending an RCS message, rich card, carousel, or suggested-action message; checking device RCS capability; configuring RCS-to-SMS fallback; provisioning an RCS agent; or sending typing indicators."
metadata:
  author: Sinch
  version: 1.2.0
  category: Messaging
  tags: rcs, rich-card, carousel, suggested-actions, choice-message, rbm, capability-check, sms-fallback, typing-indicator, conversation
  uses:
    - sinch-conversation-api
    - sinch-authentication
    - sinch-sdks
    - sinch-provisioning-api
---

# Sinch RCS

## Overview

RCS (Rich Communication Services) enables rich, branded messaging in the native device messaging app — including rich cards, carousels, suggested actions, media messages, location messages, read receipts, and typing indicators. When a device does not support RCS, configure automatic fallback to SMS.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Apply the shared evidence tiers. Fetch the exact canonical operation, schema, or security page before emitting Tier B details; record one source per coherent contract in the evidence ledger. If the fetch fails, follow the shared fail-closed rule instead of substituting bundled content.

`scripts/**` are execution tools: 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 10 — file references are metadata, not package contents.

View saved version →

---
name: sinch-sdks
description: "Sinch SDK installation and client initialization for Node.js, Python, Java, and .NET. Use when installing a Sinch SDK, initializing SinchClient, setting up SDK credentials, configuring conversation region in SDK, or building a multi-product SDK client. For In-App Calling SDKs, see sinch-in-app-calling."
metadata:
  author: Sinch
  version: 1.2.0
  category: Core
  tags: sdk, node, python, java, dotnet, sinch-client, installation
  uses:
      - sinch-authentication
---

# Sinch SDKs

## Overview

Cross-cutting skill that covers SDK installation and client initialization for all Sinch products. Determines the correct SDK and provides init code per language.

For authentication setup (credentials, OAuth2, Basic auth, signed requests), see `sinch-authentication`. For In-App Calling SDKs (Browser, iOS, Android), see `sinch-in-app-calling`.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

If the user hasn't specified which language or platform, ask first — the SDK and init pattern differ by language. Use the table below to route to the correct reference.

## Source of Truth — what to load, and what is authoritative

This skill has two kinds of content with UNEQUAL reliability. Follow this precedence:

1. **Canonical docs at `developers.sinch.com` (AUTHORITATIVE).** The `.md` doc links in
   this skill are the single source of truth for exact request/response schemas, field
   names and nesting, enum values, signature/auth sc

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: sinch-sms
description: "Sends and receives SMS text messages via the SMS channel of the Sinch Conversation API. Covers sender ID types (long code, short code, alphanumeric, toll-free, 10DLC), GSM 7-bit vs UCS-2 character encoding, concatenated multi-part messages, opt-out (STOP) handling, and SMS channel properties. Use when sending an SMS or text message, handling inbound SMS or STOP keywords, choosing or configuring an SMS sender ID, or debugging encoding and message-part issues."
metadata:
  author: Sinch
  version: 1.2.0
  category: Messaging
  tags: sms, text-message, sender-id, short-code, alphanumeric, toll-free, 10dlc, encoding, gsm-7, ucs-2, opt-out, conversation
  uses:
    - sinch-conversation-api
    - sinch-authentication
    - sinch-sdks
---

# Sinch SMS

## Overview

SMS is a core channel of the Sinch Conversation API. The API handles SMS-specific details like encoding detection and message concatenation automatically. This skill covers everything SMS-specific: sender IDs, encoding, message parts, opt-out compliance, and SMS channel properties.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Apply the shared evidence tiers. Fetch the exact canonical operation, schema, or security page before emitting Tier B details; record one source per coherent contract in the evidence ledger. If the fetch fails, follow the shared fail-closed rule instead of substituting bundled content.

`scripts/**` are execution tools: run them as-is to per

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: sinch-verification-api
description: Verify phone numbers via SMS, Flashcall, Phone Call, Data (seamless carrier-level), or WhatsApp with Sinch Verification API. Use when implementing user phone verification, OTP, two-factor authentication, or number ownership confirmation flows.
metadata:
  author: Sinch
  version: 1.2.0
  category: Verification
  tags: verification, otp, sms, flashcall, 2fa, phone-verification, whatsapp
  uses:
    - sinch-authentication
    - sinch-sdks
---

# Sinch Verification API

## Overview

The Sinch Verification API verifies phone numbers through SMS OTP, Flashcall (missed call CLI), Phone Call (spoken OTP), Data (carrier-level), and WhatsApp OTP. Used for registration, 2FA, and number ownership confirmation.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block implementation:

1. **Verification method** — `sms`, `flashcall`, `callout`, `seamless`, or `whatsapp`.
2. **Approach** — do not ask. Default to the official Sinch SDK for the resolved language; use direct API calls (curl, `fetch`, `requests`) only when the request or an existing dependency already chooses them, or no official SDK covers the language or operation. State the chosen approach.
3. **Language** — for SDK: Node.js, Python, Java, or .NET. For direct API: any language, or curl.

When using the **SDK**, r

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-voice-api
description: Build voice apps with the Sinch Voice API v1. Use for phone calls, text-to-speech (TTS), IVR menus, DTMF input, conference calling, call recording, call forwarding, answering machine detection (AMD), SIP routing, WebSocket audio streaming, and SVAML call control. Not for Voice API v2 (public preview); use the sinch-voice-api-v2 skill for that.
metadata:
  author: Sinch
  version: 1.3.0
  category: Voice
  tags: voice, calls, tts, ivr, dtmf, conference, recording, svaml, sip, amd, webrtc
  uses:
    - sinch-authentication
    - sinch-sdks
---

# Sinch Voice API

## Overview

The Sinch Voice API lets you make, receive, and control voice calls programmatically via REST. It uses **SVAML** (Sinch Voice Application Markup Language) to define call flows through callback events.

> **Version scope: Voice API v1 only.** This skill covers the `/calling/v1` API, its SVAML dialect, and its ICE/ACE/PIE/DiCE callbacks. Sinch also offers **Voice API 2.0**, currently in public preview, with a different API surface. If the user asks for Voice 2.0, v2 endpoints, or the preview API, do not adapt the v1 guidance below. Load the `sinch-voice-api-v2` skill instead.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Before generating code, infer these from the request, prior turns, and workspace. Ask one combined question only for items that remain unresolved and block implementation:

1. **Approach** — do not ask. Default to the official S

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 12 — file references are metadata, not package contents.

View saved version →

---
name: sinch-voice-api-v2
description: Build programmable calling with the Sinch Voice API v2 (public preview). Use for creating outbound calls, handling Voice v2 webhooks, writing SVAML v2 call flows, IVR menus, bridging call legs, call recording, batch calling, connecting Voice Relay or raw audio streams to AI voice agents, and migrating Voice v1 call control to v2. Not for Voice API v1 callouts and ICE/ACE/PIE callbacks (use sinch-voice-api), the In-App Calling SDKs, or Elastic SIP Trunking.
metadata:
  author: Sinch
  version: 0.3.0
  category: Voice
  tags: voice, voice-v2, calls, svaml, ivr, bridge, recording, batch, voice-relay, voice-stream, webhooks
  uses:
    - sinch-authentication
    - sinch-sdks
---

# Sinch Voice API v2

## Overview

The Sinch Voice API v2 provides project-scoped REST resources for creating, receiving, and controlling calls with SVAML v2 commands. Use it for PSTN and SIP calls, IVR, bridging, recording, batch calling, and for connecting AI voice agents through Voice Relay or raw WebSocket audio streams.

> **Version scope: Voice API v2 (public preview) only.** This skill covers the `/v2/projects/...` API, SVAML v2 commands, and CloudEvent webhooks. Voice API v1 (`/calling/v1`, application key and secret, ICE/ACE/PIE callbacks) has a different surface; do not adapt the guidance below to v1. Load the `sinch-voice-api` skill for v1 instead. Preview contracts can change; confirm every wire detail against the linked docs in the current session.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sinch-whatsapp
description: "Sends WhatsApp Business messages via the WhatsApp channel of the Sinch Conversation API — text, media, interactive, and Meta-approved template messages. Covers the 24-hour customer service window, template approval, opt-in requirements, and media specifications. Use when sending a WhatsApp message or WhatsApp template, re-engaging users outside the 24-hour window, handling WhatsApp opt-ins, or debugging failed WhatsApp sends."
metadata:
  author: Sinch
  version: 1.2.0
  category: Messaging
  tags: whatsapp, whatsapp-business, template, 24-hour-window, service-window, opt-in, meta, interactive-message, conversation
  uses:
    - sinch-conversation-api
    - sinch-authentication
    - sinch-sdks
    - sinch-provisioning-api
---

# Sinch WhatsApp

## Overview

WhatsApp Business messaging is available through the Sinch Conversation API. Send text, media, template, and interactive messages using the unified API format. WhatsApp has strict rules around messaging windows and template approval — this skill covers those channel-specific rules.

## Agent Instructions

> **Policy gate `sinch-shared-policy@5` (`sha256:4864cf0fa8d6`):** The policy digest below is binding as written. Before implementation or live execution, read [the full shared Sinch policy](references/shared-policy.md) once per conversation — skip it if this exact ID/version/fingerprint is already loaded; read it if the version is newer or the fingerprint differs. This skill's canonical operation routes live in its Agent Instructions and Links sections.

<!-- sinch-policy-digest: start (generated; edit docs/SINCH_SHARED_POLICY.md and run scripts/sync_sinch_skill_references.py) -->
**Sinch policy digest (binding):**

1. Load the shared policy once per conversation; skip duplicate copies bearing the same ID/version/fingerprint.
2. Infer product, language, region, and environment from the request and workspace; ask one combined question only for true blockers. Prefer the official Sinch SDK unless the request or workspace decides otherwise or no official SDK covers the language or operation.
3. Code-generation approval is not execution approval. Classify every operation (read-only / reversible / billable / destructive) and obtain explicit approval before billable or destructive calls.
4. Tier B facts — endpoint paths, methods, field names, enums, limits, webhook payloads, signature algorithms, SDK signatures — require fetching the exact canonical document in the current session before use.
5. Bundled scripts, references, and examples are Tier C: illustrations, never schema authority. Never promote example values to production defaults.
6. If a route is unresolved or a canonical fetch fails, climb the resolution ladder in order — re-search already-fetched documents (raw, not summarized), consult https://developers.sinch.com/llms.txt, follow first-party links, retry once — before failing closed. Never pattern-guess a documentation URL; never substitute memory, search snippets, or bundled files.
7. Keep an evidence ledger mapping each fetched source to the fields and claims it authorized.
8. Bound all polling and retries (backoff, jitter, hard cap); check state before retrying billable or destructive operations; report a timeout as unknown, not failed.
9. Report verification levels separately (lint → unit → mock contract → sandbox → live → end-to-end); an HTTP 2xx does not prove delivery. State the levels not performed.
10. Load only the smallest skill set that owns the behavior; if a required skill is unavailable, name it and stop rather than improvising its instructions.
<!-- sinch-policy-digest: end -->

Apply the shared evidence tiers. Fetch the exact canonical operation, schema, or security page before emitting Tier B details; record one source per coherent contract in the evidence ledger. If the fetch fails, follow the shared fail-closed rule instead of substituting bundled content.

WhatsApp template payloads are Meta-driven and cha

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.