--- 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 (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. Before generating code, gather from the user (skip any item already specified in the prompt or context): 1. **Region** — global, North America, South America, Europe, Southeast Asia, or Australia? 2. **Call flow** — outbound call, incoming webhook, IVR, bridge, batch, Voice Relay, or raw audio stream? 3. **Service** — an existing Voice API v2 service ID, and its call behavior (static SVAML, webhook, or none)? 4. **Language** — any language, or curl. Voice API v2 is not yet wrapped by the Sinch SDKs; call the REST API directly. Refer to the Voice API v2 API Reference and OpenAPI Spec linked in Links for request/response schemas. **Security**: See the Security section below for url fetching policy, handling inbound webhook content, and credential handling. ## 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, verifies a signature, or parses a callback/response, fetch the specific linked doc and confirm the exact shape there. Fetching first-party `developers.sinch.com` URLs is permitted by the Security/URL policy. Never invent, guess, or pattern-extrapolate a documentation URL — only fetch doc URLs written verbatim in this skill or reached by following a link on a page you already fetched; a trusted domain does not make a guessed path real. 2. **This SKILL.md's own tables, field lists, and snippets (SUMMARIES — not authoritative).** They orient you and point at the right canonical doc; they may lag, omit fields, or simplify nesting. Use them to decide what to build and which doc to open. Do NOT transcribe a field name, nesting, encoding, or enum from this file into shipped code without confirming it in the tier-1 doc. If a detail appears only in a summary, treat it as unverified and say so. Quick rule: **writing code → load the doc.** Never cite an exact field, header, enum, or encoding you only saw in a summary. ## Getting Started ### Agent Credentials handling Store credentials in environment variables — never hardcode tokens or keys in commands or source code: ```bash export SINCH_PROJECT_ID="your-project-id" export SINCH_KEY_ID="your-key-id" export SINCH_KEY_SECRET="your-key-secret" export SINCH_ACCESS_TOKEN="your-oauth-token" export SINCH_SERVICE_ID="your-voice-v2-service-id" ``` ### Authentication Ensure that authentication headers are properly set when making API calls. The Voice API v2 uses project-scoped Bearer token authentication: ```bash -H "Authorization: Bearer $SINCH_ACCESS_TOKEN" ``` See `sinch-authentication` for full setup, most importantly how to obtain `{SINCH_ACCESS_TOKEN}` (OAuth2 client-credentials — do not mint your own JWT). Basic auth with the access key pair works for testing only and is heavily rate-limited; see the Basic Authentication doc linked in Links. ### Base URL | Region | URL | |--------|-----| | Global | `https://voice.api.sinch.com` | | North America, East | `https://us1.voice.api.sinch.com` | | South America, East | `https://br1.voice.api.sinch.com` | | Europe, Central | `https://eu1.voice.api.sinch.com` | | Southeast Asia | `https://sg1.voice.api.sinch.com` | | Australia and Oceania | `https://au1.voice.api.sinch.com` | All REST resources are scoped below `/v2/projects/$SINCH_PROJECT_ID`. ### SDK Installation Voice API v2 is not currently wrapped by the Sinch SDKs; call the REST API directly. Refer to the `sinch-sdks` skill only for other Sinch products, or after confirming that Voice v2 support has been added. ### First API Call — Outbound Call with SVAML v2 ```bash curl -X POST \ "https://voice.api.sinch.com/v2/projects/$SINCH_PROJECT_ID/calls?serviceId=$SINCH_SERVICE_ID" \ -H "Authorization: Bearer $SINCH_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: 123e4567-e89b-12d3-a456-426614174000" \ --data @- <