Start with
the protocol.
Learn the core contracts behind a provider-neutral Farcaster client. This guide applies whether you build a web app, mobile client, desktop application or a headless service.
Four boundaries to understand
Protocol domain
Normalize FIDs, casts, follow links, message hashes and identity independent of backend vendors.
02Provider adapters
Declare actual capabilities and decode each API into a canonical model.
03Local persistence
Keep stable entities, freshness metadata and route-scoped cursors for offline-first reads.
04Signing and publishing
Separate the authorized signer from a validator-bound durable write queue.
Integrating a new read node
1 Select the API contract
Raw protocol endpoints and indexed social APIs implement different feature sets. Determine the contract before configuring an address or attempting data decoding.
2 Register the provider
Store a stable provider identifier, endpoint, capabilities, auth requirements and privacy category. Keep the chosen provider separate from the actual runtime route until the change is applied.
3 Probe representative reads
Test actual API response shapes and record measured latency. HTTP success does not establish full chain sync or permission to publish. For browsers, transport and CORS restrictions are additional concerns.
4 Normalize and cache
Convert vendor response objects into canonical protocol records, attach source provenance and persist them before exposing the result.
5 Enforce fallback policy
When an optional feature is absent, return an explicit unsupported result unless the user has authorized a compatible alternate provider. Never silently contact another node.
Basic read request flow
Offline operation means reading previously cached records. It does not mean the local database is automatically a full protocol replica.
Next steps
Implement these backend contracts in any programming language →