Answers to the questions integrator teams ask most, organized by where you are in the journey: evaluating, architecting, integrating, operating. Each answer is short on purpose; the deep-dive links at the end of a section are the authoritative reference.
Pouchy is the relationship layer for AI agents: a hosted platform that gives your agent persistent memory, executable skills, a wallet with human-confirmed payments, agent-to-agent social ability, generative UI, and 82 messaging channels — behind one API. You define an agent (persona, skills, permissions) in the dashboard; your users talk to it over your app (via SDK sessions) or any connected channel, and it remembers them across sessions, forever.
With a raw LLM API you own: memory extraction and recall, tool execution and its permission model, per-channel webhook verification and event parsing, identity mapping, usage metering, voice, and payment confirmation flows. Pouchy ships all of that as the platform, model-agnostic (the LLM provider is a server-side setting, not your integration surface). The trade is the same one every managed platform offers: you integrate against our contracts instead of building your own plane.
Three: an in-app companion (your app mints a session with your own user id and talks over the JS/Flutter/Unity SDK, including real-time voice); a channel bot (connect Telegram, WhatsApp, Slack, a support inbox or 78 others from the dashboard — no code, full agent runtime); and a data-plane agent (the agent reads views and performs actions against YOUR backend, with signed requests and per-action confirmation policy).
Deep dives: Integrator Quickstart· Quickstart: Agent Data Plane
Use YOUR user id as the externalUserId when minting sessions. The instance — memory, history, persona state — is keyed by project + externalUserId, so every surface you route through that id shares one brain. This is the deep-integration path and it is the ONLY path that unifies one human across multiple channels: you receive channel events on your own infrastructure, map the channel identity to your unified id, then call Pouchy with it.
The channel-side id (a Telegram numeric id, a WhatsApp id, and so on), per connector. Native channels run the complete agent runtime, but the platform cannot know that a Telegram user and a WhatsApp user are the same person — so cross-channel memory unification structurally belongs to the unified-id pattern above, not to native channels.
Yes, deliberately. Instances created by non-web native channels share the same id space as API-minted sessions, so your backend can mint a session with the channel-side id and operate on the same instance (read and write memory, inject data events). The web widget is the one exception: its instances live in a reserved namespace, isolated from API-minted instances by design (anti-impersonation), and it is also the one channel where you can inject your own user id (visitorId plus a server-side HMAC via verifyVisitor).
On native channels, the provider's webhook terminates at Pouchy; you get pull-style views (usage APIs, event receipts), not the raw payloads. What the platform pushes outward are its own platform events: subscribe an HTTPS endpoint via the project webhooks API (/v1/projects/…/webhooks — HMAC-signed, with delivery history, test fires and redelivery) to eleven event types — channel signups, usage and billing thresholds, agent lifecycle (nudges, scheduled fires, awaiting-decision runs, cost alerts, event replies) and referral conversions. Those are platform notifications, not the provider's raw payloads. If full-fidelity event retention on your side is a requirement, self-integrate the channels and use the session API.
Yes — end users can trigger explicit memory forgetting in conversation, and account-level erasure removes stored identity material. Retention questions beyond that (contractual DPA terms, region pinning) are enterprise-plan conversations.
82 transports across IM (Telegram, WhatsApp, Messenger, Instagram, Discord, Slack, Teams, Signal, Viber, Matrix, iMessage and more), support inboxes (Intercom and the creator-DM class), regional platforms (WeChat, WeCom, LINE, KakaoTalk, Feishu, DingTalk, QQ and more), voice assistants, e-mail, SMS, and the embeddable web widget. The dashboard Channels page is the live list.
No. A channel inbound drives the same run core as an SDK session: full memory extraction and recall, server-side skills, HTTP/MCP tools, image attachments (vision) and file attachments (text extraction), keyword-confirmed sensitive actions, and metering — identical to the API path.
Yes — group mode gives a room one shared brain (shared memory and transcript for all members), with speaker attribution and a mention/wake-word gate so the agent only speaks when addressed.
Minutes: create the connector in the dashboard (or via the Admin API), paste the provider credentials, register the minted inbound URL with the provider. Telegram and Discord are self-registering — the platform performs the webhook registration for you at create time.
Deep dives: Channel setup — per-provider guide· Group mode
Plan tiers cap monthly active users (MAU — unique end users who talked to your agents that month): Free 10 MAU (forever), Pro 1,000 ($49/mo), Scale 10,000 ($259/mo), Enterprise custom. Compute usage is metered in credits (plan allowances 500 / 10,000 / 100,000 per month) and real-time voice has its own minute ceiling per plan (20 / 400 / 4,000). The dashboard billing page is the authoritative live statement of your plan, usage, and the current numbers.
Existing active users keep working mid-month; the MAU gate refuses NEW users beyond the cap with an HTTP 402 naming the numbers. If the platform temporarily cannot read your billing state, a gated mint answers a retryable 503 instead of quoting limits it never read — retry, and you get either a mint or the real verdict. Usage-threshold webhooks fire at 80% and 100% of the credit allowance so you are never surprised.
No — users minted with a test key meter into a separate bucket that is never gated and never billed. Build, test, and publish without spending your MAU budget.
Per-provider signature verification, fail-closed where the vendor always signs; connectors carry encrypted secrets; signed inbound URLs are treated as credentials and are invalidated on rotate. Replay windows and event-id dedup are standard. The one client-asserted identity (the web widget) has a documented server-side HMAC hardening (verifyVisitor).
Sensitive tools (payments, outbound messages, custom skills you flag) go through an explicit human confirmation step — in-app confirm cards, or keyword confirms relayed over the channel. Per-tool auto-run exemptions are an operator decision, not a default.
Yes — SAML/OIDC SSO with SCIM provisioning for dashboard access.
Project secret keys are server-side only and mint short-lived session tokens with narrowed scopes; the browser only ever holds the session token. Test and live keys are separate. Admin-plane keys are a distinct credential with their own audit trail.
Deep dives: Enterprise SSO runbook
TypeScript/JavaScript (npm plus a CDN bundle), Python, Flutter, Unity, React bindings, a backend kit for the data-plane receiver, and a C# reference receiver. The API reference documents the wire contract all of them ride.
The Integrator Quickstart (token, connect, chat, voice, tools, memory) — or, for the no-code path, connect a Telegram bot from the dashboard and message it. Both are under an hour.
The protocol carries an explicit version; additive changes are the norm and breaking changes go through a documented deprecation window.
The API reference and the per-feature deep-dive docs win; this FAQ is a map, not the territory. Tell us and we fix the FAQ.
Deep dives: API Reference· API Versioning