Architecture
There’s one client, and a few ways to reach it. @flynetdev/core is the foundation; everything else is built on it or points back to it. Build on the layer that matches your stack — they compose, they don’t compete.
Build on the core client
@flynetdev/core is the supported way to call Flynet — a typed TypeScript client with both auth schemes built in (X-API-Key Discovery, OAuth member context), the OAuth flow, typed errors, and money and pagination helpers. Use it directly from any backend or non-React app. Don’t hand-roll HTTP against the API; the client is the contract.
Add the React layer for UI
@flynetdev/react is @flynetdev/core plus a data and UI layer — a provider that manages caching, hooks, and drop-in components. It’s the fast path to rendering discovery and member context, and it exposes the underlying core client when you need to drop down a level.
Reach the same core from an agent
The agent tooling doesn’t add an API — it puts the same client in front of an AI coding agent:
- The API MCP is
@flynetdev/core wrapped as agent tools.
- The agent skill and Cursor rules teach the agent that same auth model and point it at
@flynetdev/core and @flynetdev/react.
- The Docs MCP keeps the agent’s knowledge of all of it current.
An agent writing Flynet code and a developer writing it are building against the same client, the same way.
Which layer to build on
| You’re building | Build on |
|---|
| A React app | @flynetdev/react |
| A backend or non-React client | @flynetdev/core |
| Anything, with an AI agent | the Build with AI surfaces |
@flynetdev/core is generated from Flynet’s API contract and hand-finished, so its types match the live API and stay in sync as it evolves. Building on the client — rather than raw HTTP — is how your integration inherits that.
Next