sinch-functions-node

Sinch Functions — Node.js 运行时

概述

Sinch Functions 目前处于测试阶段：测试期间免费，正式发布前 API 可能会发生变化。

软件包：@sinch/functions-runtime（npm）。编写 TypeScript/JavaScript 函数，以接听电话、处理对话 Webhook 并提供自定义 HTTP 端点。

Voice API v2 是 context.voice 所对应的 API，也是新函数的编写目标。未带版本号的名称始终指当前 API：context.voice 是 v2。由于 developers.sinch.com 尚无针对 v2 的 Functions 页面，以下 v2 部分优先介绍。现有 Voice v1 函数会继续照常运行；请参阅 Voice v1 回调。

相关技能：

• sinch-functions — 平台概述、概念和运行时选择
• sinch-cli — 终端命令（sinch functions dev、sinch functions deploy 等）
• sinch-voice-api-v2 技能涵盖 Voice API v2；加载该技能以了解 REST 契约、SVAML v2 命令和服务配置。
• sinch-functions-dotnet — 使用 C# 实现相同概念

Agent 指令

策略门槛 sinch-shared-policy@5（sha256:4864cf0fa8d6）： 以下策略摘要按原文具有约束力。在实施或实时执行前，每次对话都要阅读一次完整的 Sinch 共享策略；如果此确切 ID／版本／指纹已加载，则跳过；如果版本更新或指纹不同，则阅读。本技能的规范操作路由位于其 Agent 指令和链接部分。

Sinch 策略摘要（具有约束力）：

1. 每次对话加载一次共享策略；跳过具有相同 ID／版本／指纹的重复副本。
2. 根据请求和工作区推断产品、语言、区域和环境；只有遇到真正的阻碍时，才提出一个合并问题。除非请求或工作区另有决定，或没有官方 SDK 支持该语言或操作，否则优先使用官方 Sinch SDK。
3. 获准生成代码不代表获准执行。对每项操作进行分类（只读／可逆／计费／破坏性），并在进行计费或破坏性调用前取得明确批准。
4. B 级事实——端点路径、方法、字段名称、枚举值、限制、webhook 负载、签名算法、SDK 签名——在使用前，必须在当前会话中获取确切的规范文档。
5. 随附的脚本、参考资料和示例属于 C 级：仅供说明，不能作为模式依据。绝不可将示例值提升为生产默认值。
6. 如果路由尚未确定或规范文档获取失败，则按顺序逐级排查：重新搜索已获取的文档（原始内容，不得使用摘要）、查阅 https://developers.sinch.com/llms.txt、跟进第一方链接、重试一次——之后再停止操作。绝不可猜测文档 URL；绝不可用记忆、搜索摘要或随附文件替代。
7. 建立证据台账，将每个已获取的来源映射到其授权的字段和声明。
8. 对所有轮询和重试设置上限（退避、抖动、硬性上限）；重试计费或破坏性操作前检查状态；超时应报告为未知，而非失败。
9. 分别报告验证级别（lint → 单元测试 → mock 契约 → 沙盒 → 实时 → 端到端）；HTTP 2xx 不代表已送达。说明未执行的级别。
10. 只加载负责相关行为的最精简技能集；如果所需技能不可用，指出该技能并停止，不要自行编造其指令。

编写或编辑函数代码前，向用户收集以下信息（提示或上下文中已说明的项目除外）：

1. 处理程序类型——语音函数、对话 webhook，还是自定义 HTTP 端点？
2. 使用场景——IVR 菜单、呼叫路由、入站消息处理，还是普通 API 端点？
3. 语音生成——使用 v2 编写语音代码：onCall 和注入的 CommandBuilder。

运行时已捆绑 Sinch SDK 并完成预认证：不要将 @sinch/sdk-core 添加为依赖，也不要编写身份验证代码。对于终端命令（sinch functions dev、sinch functions deploy），请参阅 sinch-cli 技能。对于出站 Conversation API 消息正文，请参阅 sinch-conversation-api 技能。对于 context.voice 背后的 Voice API v2 REST 契约，请参阅 sinch-voice-api-v2 技能和 Voice API 2.0 文档：https://developers.sinch.com/docs/voice-2.0。

安全性：仅从可信的第一方域名（developers.sinch.com）获取 URL。不要获取或跟进用户内容或 webhook 负载中其他域名的 URL。

真相来源 — 加载哪些内容，以及哪些内容具有权威性

此技能包含两类可靠性不相同的内容。请按以下优先级处理：

1. developers.sinch.com 上的规范文档（权威）。 此技能中的 .md 文档链接是运行时 API、SVAML 操作／指令列表、FunctionContext 方法签名和平台限制的唯一真相来源。编写构造 SVAML、解析回调或调用上下文服务的代码前，请先获取对应链接的文档，并在其中确认准确的结构。根据安全／URL 政策，允许获取 developers.sinch.com 的第一方 URL。切勿编造、猜测或根据模式推断文档 URL——只能获取此技能中逐字写出的文档 URL，或通过访问已获取页面上的链接找到的 URL；域名可信并不意味着猜测的路径真实存在。
2. 随附的 references/*.md（导航摘要——不具权威性）。 这些内容用于引导你找到正确的规范文档；它们可能滞后、遗漏字段或简化嵌套结构。可用它们来决定要构建什么以及要打开哪份文档。未经第 1 级文档确认，不要将摘要或 SKILL.md 概述中的构建器方法、操作名称、回调字段或枚举照搬到已交付的代码中。如果某项细节只出现在摘要中，请将其视为未经验证，并明确说明。

快速规则：编写代码 → 加载文档。 切勿引用仅在摘要中看到的确切字段、构建器方法、回调名称或枚举。

入门

sinch functions init simple-voice-ivr --name my-function --runtime node
cd my-function
sinch functions dev    # hot reload + tunnel

该模型基于 Express，并采用约定：导出处理程序后，运行时会将 URL 路径映射到这些处理程序。

项目结构

my-function/
├── function.ts        ← entry point — all exports live here
├── package.json
├── tsconfig.json      ← shared config, don't change module settings
├── sinch.json         ← project manifest
├── .env               ← local dev secrets (gitignored)
├── assets/            ← private files, read with context.assets()
└── public/            ← static files, served at /

所有源文件都放在项目根目录——运行时要求文件采用扁平结构。可将逻辑拆分到 harness.ts、db.ts 等文件中，并从 function.ts 导入。

入口点：function.ts。每个命名导出都会成为一个 HTTP 端点；onCall 会构建语音函数所需的那个导出。

import { onCall } from '@sinch/functions-runtime/voice';

export const voiceWebhook = onCall({
  incoming: (call, builder) => builder.answer().say('Thanks for calling.').hangup(),
  completed: (call) => {
    console.log('call ended', call.callId);
  },
});

核心概念

FunctionContext 和随附的 Sinch SDK

作为第一个参数传递给每个处理程序：

interface FunctionContext {
  config: FunctionConfig;         // projectId, functionName, environment, variables
  cache: IFunctionCache;          // key-value cache with TTL
  storage: IFunctionStorage;      // file/blob storage
  database: string;               // path to SQLite database file
  requestId?: string;             // tracing ID for this request
  timestamp?: string;             // ISO 8601 request timestamp
  env?: Record<string, string | undefined>;
  voice: VoiceClient;             // Voice API v2 — always present
  conversation?: ConversationService;  // pre-authenticated when configured
  sms?: SmsService;               // pre-authenticated when configured
  numbers?: NumbersService;       // pre-authenticated when configured
  assets(filename: string): Promise<string>;  // read files from assets/
}

（仅为摘要——实施前，请对照权威的 Function context 参考文档，确认准确的属性名称和类型。）

官方 @sinch/sdk-core SDK 已随附，并为每种产品预先完成身份验证——你无需自行安装或编写身份验证代码。以下四个客户端可通过平台注入的环境变量在 context 上直接使用；如果未设置某个产品的凭据，其属性将为 undefined（但 context.voice 始终存在，只有发送请求时才会报告缺少凭据）——请始终使用可选链：await context.sms?.batches.send(...)。对于其他产品（Verification、Number Lookup、Fax、Elastic SIP Trunking 等），请使用相同的项目凭据自行构造该产品的客户端——无需额外的 npm 依赖，因为 @sinch/sdk-core 已是 @sinch/functions-runtime 的依赖项，并且可从 node_modules 解析：

import type { FunctionContext } from '@sinch/functions-runtime';
import { SinchClient } from '@sinch/sdk-core';

export function verificationClient(context: FunctionContext): SinchClient {
  return new SinchClient({
    projectId: context.config.requireVariable('PROJECT_ID'),
    keyId: context.config.requireVariable('PROJECT_ID_API_KEY'),
    keySecret: context.config.requireVariable('PROJECT_ID_API_SECRET'),
  });
}

有关 SinchClient 构造函数，请参阅 sinch-sdks 技能；有关其 API，请参阅对应的产品技能（例如 sinch-verification-api）。缓存、存储和数据库服务请参阅 references/context-services.md。

端点路由

URL 路径的最后一段映射到导出名称。Voice v2 是例外：该服务的每个 call.* 事件都会发送到函数根路径，并按事件名称分派，因此平台只需要 voiceWebhook 这一个导出。对话 Webhook 和自定义 HTTP 端点可以使用默认导出，也可以声明为具名的 export async function。

URL 路径	调用的导出	类型	规则
POST /，请求体包含 call.* 事件	voiceWebhook	Voice v2	按请求体中的事件名称路由，而非按路径路由
POST /webhook/conversation	conversationWebhook	对话 Webhook	两种写法均可。/webhook/<service> → <service>Webhook（驼峰命名 + Webhook 后缀）
GET /status	status	自定义 HTTP	两种写法均可
GET /api/health	health	自定义 HTTP	以路径的最后一段为准：/api/v2/users → users
GET /	default 或 home	自定义 HTTP 根路径	home 是适合 TypeScript 的别名

（仅为摘要——实现前，请根据权威的 Handlers 文档确认确切的路径到导出映射规则。）

呼叫生命周期

入站呼叫通过 Voice v2 服务到达函数：sinch functions init 会选择一个服务，并将其 ID 写入 .env 中的 VOICE_SERVICE_ID（v2 标记；v1 使用 VOICE_APPLICATION_KEY）；sinch functions deploy 会将该服务的 Webhook 指向已部署的函数。入站事件是发送到函数根路径的 CloudEvents；onCall 接收按生命周期阶段设定的处理程序，并将每个事件映射到其中一个处理程序。

事件	处理程序	触发时机
call.incoming	incoming	入站呼叫到达该服务上的某个号码
call.answered	answered	出站呼叫被接听
call.menu、call.webhook.*	manage	呼叫中的决策点——菜单输入或 webhook 命令
call.hangup、call.failed	completed	呼叫结束

onCall 还接收一个 webhooks 映射，键为 webhook 命令触发时使用的名称；此外还接收一个 fallback，用于处理未被认领的事件。每个处理程序都按 (call, builder, context, request) 的形式调用——call 是扁平结构（call.from、call.callId、call.event），并根据处理阶段使用对应类型：incoming 接收 IncomingCall，manage 接收 MenuCall，当 call.event === 'call.menu' 时其 menu 保证存在，completed 接收 CompletedCall。返回 builder（.build() 可选），运行时会生成线上请求体；不返回内容则响应 204。call.call——扁平化之前读取呼叫信息的方式——已弃用，但尚未移除：它仍可编译，仍会返回 call 本身，但不会出现在线上请求中。请直接从 call 读取字段；新代码不应使用 call.call。

命令构建器

运行时会预先初始化一个 CommandBuilder，并将其作为第二个参数传给处理器。将命令链式添加到构建器上并返回它——不要手动编写 JSON：

import { onCall } from '@sinch/functions-runtime/voice';

export const voiceWebhook = onCall({
  incoming: (call, builder) => builder.answer().say('Thanks for calling.').hangup(),
});

构建器的 dialPhone、dialSip、dialStream 和 dialRelay 会将另一方接入通话：它们会将来电方桥接到新的通话支路，并在另一方挂断时结束每条支路。由于构建器了解当前通话，它会自动填写原本需要手动编写的内容——支路名称、桥接、拆除操作和 from。它们不会接听通话：answer() 仍需显式调用。onNoAnswer 会一次性处理忙线、拒接、超时和失败，并接收完整的流程。dialAgent 也会以同样的方式桥接到基于 SIP 的 AI Agent（ElevenLabs、Grok）——请参阅下文“将通话连接到 AI Agent”。

在菜单中，option 接受字面按键（0-9、*、#）；match 接受正则表达式。say、dialPhone 等函数也有独立版本，可启动新流程，适用于需要传入流程的场景——菜单选项、onNoAnswer、onFail。

有关实时通话支路规则、处理器/事件表、容易忽略的行为（AMD、say+hangup 的时序、'voice-relay' 的拼写）以及 IVR/Agent 转接示例，请参阅 references/voice.md。如需查看完整的 CommandBuilder 方法表，请通过 node_modules/@sinch/functions-runtime/dist 下的 .d.ts JSDoc 使用 IntelliSense，或查阅 Node.js runtime guide——此技能不会维护方法目录。

（仅为摘要——实现前，请根据 https://developers.sinch.com/docs/voice-2.0 上的 Voice API 2.0 API 参考（另请参阅 sinch-voice-api-v2 技能）确认具体的方法集和参数结构。）

使用 context.voice 发起通话

context.voice 是 v2 客户端，使用项目 Access Key 密钥对（PROJECT_ID_API_KEY / PROJECT_ID_API_SECRET）进行身份验证。它可以发起通话、桥接通话支路、将 WebSocket 媒体流附加到正在进行的通话，并修补已接通的通话：call、callWithStream、bridge、transfer*（transferToPhone、transferToSip、transferToStream、transferToRelay、transferToAgent）、patch。

await context.voice.call('+15559876543', {
  from: '+15551234567',
  onAnswer: (c) => c.say('Your appointment is confirmed.').hangup(),
});

备用方案——context.voice.raw。 如果此客户端未建模某种通话创建结构，可使用 context.voice.flows.* 构建流程，并通过 raw 原样发送；它已完成身份验证，因此无需编写身份验证样板代码。raw 仅支持创建通话（POST /calls）——无法访问其他 Voice API v2 端点。

import { toCallBody } from '@sinch/functions-runtime/voice';

const flow = context.voice.flows.call('+15559876543', { from: '+15551234567' });
await context.voice.raw(toCallBody(flow));

语音函数所需的所有内容均可从 @sinch/functions-runtime/voice 导入（./voice/v2 是它的旧名称入口）。

将通话连接到 AI Agent

connectAgent(provider, number, { call }) 可在一次调用中，将来电桥接到基于 SIP 的 AI 语音 Agent（ElevenLabs、xAI Grok），并在 call.incoming 上运行；构建器的 dialAgent 可在流程运行的任何位置执行相同操作。realtimeAgent({ provider, prompt, tools }) 则会将对话保留在函数内部，将音频中继到供应商的实时 API，并在进程内分发工具调用。voiceRelay 会在通话中加入 Voice Relay 支路，通过 Sinch 运行的语音转文本/文本转语音服务交换文本。有关 Agent 转接示例和容易忽略的行为（包括 'voice-relay' 的拼写），请参阅 references/voice.md。

Webhook 签名

v2 事件由服务签名。每个事件都包含 Authorization: service <serviceId>:<signature> 和 x-timestamp，签名使用每个服务各自的密钥，基于原始正文、内容类型、时间戳和路径生成。只要 VOICE_SERVICE_SECRET 中设置了 Base64 密钥，运行时就会根据 WEBHOOK_PROTECTION 模式（never、deploy、always）验证签名，并以 401 拒绝验证失败的请求。

Sinch 目前尚未提供服务密钥。在提供密钥之前，如果函数启用了保护但未设置 VOICE_SERVICE_SECRET，每个进程只会记录一条警告，并继续处理 webhook；设置密钥后，验证会自动启用，无需修改代码。请保持保护开启；不要将其设为 never。在此期间，将 voiceWebhook 列入 auth，为端点启用 Basic auth。

缓存、存储和数据库

context.cache（带 TTL 的键值存储）、context.storage（文件／Blob 存储）和 context.database（每个函数独立的持久化 SQLite 数据库路径）开箱即用，无需设置。完整 API 和示例请参阅 references/context-services.md。

Conversation webhook

传入的 Conversation API webhook 会路由到 conversationWebhook 导出项（路径为 /webhook/conversation）。可用普通函数处理，也可扩展 ConversationController；使用 getText、getChannel、getContactId 等辅助函数读取事件。两种方式及完整的辅助函数列表，请参阅 references/conversation.md。出站消息正文请参阅 sinch-conversation-api 技能。

保护处理程序

除 /health 外，任何处理程序都可以要求身份验证；/health 始终绕过身份验证，用于响应平台存活探测。voiceWebhook 支持 auth，因此即使服务密钥尚不可用，也可以锁定 v2 端点。身份验证采用失败即拒绝策略：列入 auth 的处理程序会拒绝没有凭据或凭据错误的请求，而不会放行。

导出一个 auth 数组，列出要保护的处理程序（数组项也可以是静态资源路径，例如 'public/admin.html'；未列出的静态文件仍为公开状态）：

export const auth = ['webhook', 'admin']; // or '*' for every handler, incl. named static assets

export async function webhook(context, request) {
  return { received: request.body }; // only reachable with valid credentials
}

凭据是项目的 API 密钥和密钥，会自动注入为 PROJECT_ID_API_KEY 和 PROJECT_ID_API_SECRET，无需设置；也可以导出 ADMIN_USER／ADMIN_PASSWORD，作为第二组变量／密钥对，以接受替代登录方式。请求遭拒时会出现以下两种结果之一：浏览器访问该页面时，会重定向到内置的品牌化 /login 页面；其他请求（curl、脚本、fetch()）会收到正文为 JSON 的 401 响应，且不带 WWW-Authenticate 标头，因此浏览器不会弹出自己的 Basic Auth 对话框。curl -u user:pass 仍然有效，因为它会预先发送 Basic 凭据。通过 /login 登录会设置 HttpOnly 会话 Cookie，而不是在每个请求中发送 Basic 凭据；POST /logout 会清除该 Cookie。导出自定义的 login／logout 处理程序即可替换内置处理程序。（仅为摘要——实施前，请对照权威的 保护你的函数 指南确认准确的变量名。）

curl -u $API_KEY:$API_SECRET https://your-function-url/webhook

在本地开发中，除非启动 sinch functions dev 时设置了环境变量，否则会跳过身份验证。

自定义 HTTP 端点

任何非语音回调的导出项都是自定义端点：

import type { FunctionContext, FunctionRequest, FunctionResponse } from '@sinch/functions-runtime';

export async function health(context: FunctionContext, request: FunctionRequest): Promise<FunctionResponse> {
  return { statusCode: 200, body: { status: 'healthy', uptime: process.uptime() } };
}

export async function webhook(context: FunctionContext, request: FunctionRequest): Promise<FunctionResponse> {
  if (request.method !== 'POST') return { statusCode: 400, body: { error: 'POST only' } };
  return { statusCode: 200, body: { received: true } };
}

多文件函数

function.ts 是入口文件。导入时使用 .js 扩展名（NodeNext 解析）：

import { onCall } from '@sinch/functions-runtime/voice';
import { onIncoming } from './voice.js';
import { handleMessage } from './conversation.js';

export const voiceWebhook = onCall({ incoming: onIncoming });

// Conversation webhooks and custom endpoints can be named exports.
export async function conversationWebhook(context, req) { return handleMessage(context, req); }

设置钩子

可选的启动初始化和 WebSocket 端点：

export function setup(runtime) {
  runtime.onStartup(async (context) => { /* init DB, warm cache */ });
  runtime.onWebSocket('/stream', (ws, req) => { /* handle audio frames */ });
}

常见模式

• 接听来电并播报 — export const voiceWebhook = onCall({ incoming: (call, builder) => builder.answer().say('...').hangup() })。
• 将来电转接到电话号码 — 使用返回 builder.answer().dialPhone('+15551234567') 的 incoming 处理程序。添加 answered 处理程序，以便在被叫接听时执行操作。
• IVR 菜单 — 在 incoming 中使用 builder.answer().menu(name, (m) => ...)，然后在 manage 处理程序中读取 call.menu.menuName 和 call.menu.input。
• 拨打外呼电话 — 使用 await context.voice.call(to, { from, onAnswer })，或使用 callWithStream 将通话线路桥接到由你通过 setup() 提供服务的 WebSocket。
• 连接到 AI 语音 Agent — 对于基于 SIP 的供应商 Agent，使用 connectAgent(AgentProvider.ElevenLabs, number, { call })；对于在进程内维持对话的方式，使用 realtimeAgent({ provider, prompt, tools })。请参阅上文的“将通话连接到 AI Agent”和“实时 AI 语音 Agent”。
• 处理入站消息 — 导出 conversationWebhook（路径 /webhook/conversation），并使用 getText 和 getChannel 等辅助函数读取事件。请参阅 references/conversation.md。
• 自定义 HTTP 端点 — 导出任何非回调函数，并返回 { statusCode, body } 对象。将其名称添加到 auth 数组，以要求使用 Basic Auth。
• 在多次调用之间持久化状态 — 使用 context.cache 存储带 TTL 的短期键，使用 context.database 存储函数级持久化 SQLite 数据。请参阅 references/context-services.md。

注意事项与最佳实践

• 编写语音代码时使用 v2——onCall 和注入的 CommandBuilder。
• 从 @sinch/functions-runtime/voice 导入语音功能——onCall、builder 的独立工厂函数（dialPhone、dialSip、say、menu 等）、voiceRelay、realtimeAgent 和 connectAgent 都位于此子路径下（./voice/v2 是其旧名称下的相同入口）。
• call 是扁平结构，不是嵌套结构——直接读取 call.from、call.callId、call.event。call.call 仍可编译（为兼容扁平化之前编写的代码而保留），但已弃用，且不会出现在传输数据中。
• 菜单中的 option() 与 match()——option 接收字面的 DTMF 序列（0-9、*、#）；match 接收正则表达式。向 option 传入非 DTMF 模式会引发错误。
• realtimeAgent 的 Voice Relay 提供商是 'voice-relay'，不是 'relay'——没有别名；仍使用 'relay' 的示例或复制的模板将无法编译。
• 除非要演示显式覆盖，否则不要在 realtimeAgent 中硬编码模型名称——每个提供商都有自己的默认值（例如，GPT-Live 的默认值为 gpt-5.6-luna），这些默认值在运行时中设置，而不是在示例中设置。
• 不带版本号的名称才是当前 API——context.voice 是 v2 客户端。不存在名为 VoiceV2 的类型；客户端类型是 Client。
• context.voice 始终有定义，与其他 SDK 客户端不同。缺少凭据时，它会在发送请求时报告错误，而不是在访问属性时报告。
• v2 函数需要 VOICE_SERVICE_ID，而不是 VOICE_APPLICATION_KEY。sinch functions init 会写入该值，sinch functions deploy 会将服务 webhook 指向部署。
• 保持 WEBHOOK_PROTECTION 启用——只有由于 Sinch 尚未发布服务密钥，签名验证才暂时放开。将其设为 never 会永久禁用检查，即使密钥日后发布也不会恢复。
• 使用 context.assets('file.txt') 读取打包的文件。readFileSync 无法在已部署的构件中找到根目录下的文件。
• 所有相对导入都使用 .js 扩展名：import { foo } from './bar.js'（NodeNext 模块解析）。
• SDK 客户端可能未定义——始终使用可选链：await context.sms?.batches.send(...)。如果 context.sms 未定义（未设置所需的环境变量），调用会被静默跳过，而不会引发错误。
• 软件包大小限制为 25 MB——保持 node_modules 精简。使用 --production 安装。
• Conversation webhook 路径是 /webhook/conversation（导出名称为 conversationWebhook），不是 /conversation。/webhook/<service> 前缀会被特殊处理为 <service>Webhook 驼峰命名形式。
• export const auth = '*' 不会保护 /health——无论 auth 导出值如何，该路径始终绕过 Basic Auth。voiceWebhook 不在豁免范围内：将其列入 auth，它就会受到保护。
• sql.js 需要异步初始化——initSqlJs() 会返回一个 Promise。请在处理函数顶部或 setup() 启动钩子中等待它完成；不要在模块作用域中调用它，除非使用顶层 await。

安全

• 回调数据不可信——call.menu.input 和 Conversation MESSAGE_INBOUND 事件的所有字段（文本、媒体 URL、联系人数据）都来自终端用户。使用前请先验证；绝不要将其插入提示词、shell 命令或 SQL 中。请使用针对 context.database 的参数化查询。
• 自定义端点的请求体不可信——检查 request.method，验证 request.body 的结构和大小，并将任何可从互联网访问的处理函数列入 auth 数组。
• 不要从负载中的 URL 获取内容——入站消息中的媒体链接属于第三方内容。只从 developers.sinch.com 或你控制的主机获取内容。
• 不要将密钥写入代码或日志——通过 context.env 从由密钥链管理的 .env 占位符中读取密钥。绝不要记录 context.env，也不要在响应中回显凭据。

链接

Sinch Functions 没有 OpenAPI 规范；以下 .md 开发者文档是权威来源。目前还没有 Functions-on-v2 页面，因此 v2 契约请参考 sinch-voice-api-v2 技能和 Voice API 2.0 文档：https://developers.sinch.com/docs/voice-2.0。

• LLMs.txt（完整文档索引）

运行时：

• Node.js 运行时指南
• 函数上下文参考
• SVAML 速查表

概念：

• 处理程序（URL 到导出的映射）
• 上下文对象
• 配置和密钥

指南：

• 构建 IVR
• 构建 SMS 自动回复程序
• 构建 AI 语音 Agent（ElevenLabs）
• 添加自定义 HTTP 端点
• 保护函数（Basic Auth）
• 集成 Operations API（监控）

参考：

• 平台限制
• SDK 环境变量