---
read_when:
    - Ви створюєте або рефакторите шлях приймання повідомлень у плагіні каналу обміну повідомленнями
    - Вам потрібні спільне формування контексту вхідних повідомлень, запис сеансу або надсилання підготовленої відповіді
    - Ви переносите старі допоміжні функції обробки повідомлень каналів на API вхідних даних і повідомлень
summary: 'Допоміжні засоби для вхідних подій плагінів каналів: формування контексту, спільна оркестрація засобу виконання, запис сеансу та надсилання підготовленої відповіді'
title: API вхідних повідомлень каналу
x-i18n:
    generated_at: "2026-07-12T13:32:46Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: a85ffaf9501af00e1493b5fbb0454a070626ed6ca41977323b55e84b92075ed1
    source_path: plugins/sdk-channel-inbound.md
    workflow: 16
---

Шляхи отримання даних каналом відповідають єдиному потоку:

```text
подія платформи -> вхідні факти/контекст -> відповідь агента -> доставлення повідомлення
```

Використовуйте `openclaw/plugin-sdk/channel-inbound` для нормалізації вхідних подій,
форматування, коренів і оркестрації. Використовуйте
`openclaw/plugin-sdk/channel-outbound` для нативного надсилання, підтвердження отримання, надійного
доставлення та поведінки попереднього перегляду наживо.

## Основні допоміжні засоби

```ts
import {
  buildChannelInboundEventContext,
  runChannelInboundEvent,
  dispatchChannelInboundReply,
} from "openclaw/plugin-sdk/channel-inbound";
```

- `buildChannelInboundEventContext(...)`: проєктує нормалізовані факти каналу
  в контекст запиту/сеансу. Передавайте метадані відправника/чату, якими володіє канал,
  через `channelContext`, доступний хукам Plugin як `ctx.channelContext`.
  Розширюйте `PluginHookChannelSenderContext` або `PluginHookChannelChatContext`
  з цього підшляху полями, специфічними для каналу.
- `runChannelInboundEvent(...)`: виконує приймання, класифікацію, попередню перевірку, визначення,
  запис, диспетчеризацію та завершення для однієї вхідної події платформи.
- `dispatchChannelInboundReply(...)`: записує та диспетчеризує вже
  сформовану вхідну відповідь за допомогою адаптера доставлення.

Вбудовані/нативні канали, які вже отримують упроваджений об’єкт середовища виконання Plugin,
можуть викликати ті самі допоміжні засоби через `runtime.channel.inbound.*` замість
безпосереднього імпортування цього підшляху:

```ts
await runtime.channel.inbound.run({
  channel: "demo",
  accountId,
  raw: platformEvent,
  adapter: {
    ingest: normalizePlatformEvent,
    resolveTurn: resolveInboundReply,
  },
});
```

Формуйте вхідні дані `dispatchChannelInboundReply(...)` для диспетчерів
сумісності, які залишають доставлення платформою в адаптері доставлення. Нові шляхи
надсилання натомість мають використовувати адаптери повідомлень і допоміжні засоби надійних
повідомлень із `channel-outbound`.

## Міграція

Псевдоніми середовища виконання `runtime.channel.turn.*` видалено. Використовуйте:

- `runtime.channel.inbound.run(...)` для необроблених вхідних подій.
- `runtime.channel.inbound.dispatchReply(...)` для сформованих контекстів відповіді.
- `runtime.channel.inbound.buildContext(...)` для корисних даних вхідного контексту.
- `runtime.channel.inbound.runPreparedReply(...)`, застарілий, лише для
  підготовлених шляхів диспетчеризації, якими володіє канал і які вже формують власне
  замикання диспетчеризації.

Новий код Plugin не повинен запроваджувати API каналів із `turn` у назві. Зберігайте термінологію
ітерацій моделі або агента в коді агента/провайдера; Plugin каналів використовують терміни
вхідних даних, повідомлення, доставлення та відповіді.