Channels & integrations
One relationship layer. Provider rules stay where they belong.
FanLTV normalizes conversation and commercial context without pretending every channel exposes the same capabilities. Start with the channel that matters now, then add surfaces without rebuilding the model.
Alongside your current stack
FanLTV can begin as the decision layer, not a forced CRM replacement.
Keep the provider account, content library, and human team. FanLTV connects the events and context needed for one controlled workflow, then expands only when the behavior is proven.
This distinction matters: channel access, CRM operations, AI decisions, and message delivery are separate responsibilities. The pilot defines which system owns each one.
- 01ConnectUse OAuth, provider API credentials, webhook signing, or a dedicated listener depending on the channel.
- 02NormalizeMessages, media, purchases, fan identity, and delivery state enter a shared model.
- 03ControlManual, assisted, or auto mode determines whether FanLTV observes, recommends, or sends.
- 04MeasureCompare coverage, human workload, conversation quality, payment outcomes, and exceptions.
Runtime control
One integration does not mean one global switch.
Mode, pause state, price controls, and configuration status stay visible per model while provider-specific delivery remains isolated.
See the control systemCapability matrix
Integration means more than showing a logo.
The table describes the current FanLTV integration model. Exact access can still depend on provider plan, account permissions, API review, and regional availability.
| Channel | Conversation | History & events | Media & commerce | Publishing | Operational note |
|---|---|---|---|---|---|
| Fanvue | Inbound and outbound chat | History sync and webhooks | Media, priced messages, and unlock state | Channel feature dependent | Direct model connection or separate Fanvue app/OAuth workflow. |
| Fansly | Inbound and outbound chat | Backfill, sync, and Fansly events | Upload, previews, PPV, and purchase state | Scheduled FYP campaigns | Provider API and opt-in direct publishing transports are supported workflows. |
| OnlyFans | Provider API conversation flow | History, message, subscription, and purchase events | Vault/media sync and PPV workflows | Provider API dependent | Availability and rate limits follow the connected provider account and plan. |
| Telegram account | Private DMs through MTProto listener | Live listener and conversation history | Photos, video, voice, and previews | Not a feed publisher | Runs as the model's connected Telegram account with separate session security. |
| Telegram bot | Bot conversations and callbacks | Webhook updates and payment events | Stars, paid unlock flow, and post-payment delivery | Bot surface only | Bot Payments and account DMs are separate channels with separate identities. |
| Telegram Tribute | Private-chat subscription events | Signed webhook workflow | Membership/access context | Tribute-controlled | Used as a separate private-chat monetization channel, not as MTProto transport. |
| Business DM workflow | Meta webhook events | Media replies; no platform PPV | Messaging scope only | Production access depends on Meta app mode, permissions, review, and connected-tool access. | |
| Web / API | Embedded or remote chat | Signed request and response lifecycle | Site-specific subscriptions and credits | Implemented by host product | Used for sites such as AIGirlFactory through a scoped shared-token/HMAC contract. |
Available does not mean identical behavior across providers. A production readiness check validates scopes, webhooks/listeners, send permissions, rate limits, payment events, and fallback sync for the exact account.
Reliability layers
Webhooks provide speed. Recovery protects continuity.
A channel integration is production-ready only when delayed and duplicate events are handled as deliberately as the happy path.
Signed webhooks or listeners ingest supported events immediately.
Provider signatures, event namespaces, account scope, and raw-body verification remain channel-specific.
Idempotent catch-up can recover missed inbound messages where the provider permits polling, without creating duplicate replies.
Pending, sent, failed, retryable, and paid/unlocked states are recorded separately. A generated answer is not treated as delivered content.
Authentication expiry, webhook billing errors, CAPTCHA/anti-automation gates, provider 4xx/5xx responses, and ambiguous payment state are visible operational blockers.
Integration readiness check