Concepts
The small set of primitives that make CodeSpar make sense — sessions, tools, projects, triggers, authentication. Read these once and the rest of the docs clicks into place.
Concepts
@codespar/sdkv0.3.0CodeSpar is built around a handful of primitives. Most of the API surface, every framework adapter, and every cookbook can be explained by reference to the concepts on this page. Read them in order the first time — you won't need to come back.
Runtime primitives
The objects your code holds references to.
Tenancy & isolation
How CodeSpar keeps your customers' data, credentials, and usage separate.
Events & economics
What happens after the request returns.
The mental model, in one paragraph
Your application holds a CodeSpar client. For each end user it creates a Session scoped to a set of servers. The session exposes 6 meta-tools (plus optional server-specific ones). When the agent calls a tool, the Tool Router on the CodeSpar backend picks the right provider, injects the credentials (from Service Auth for your own keys, or Connect Links for end-user OAuth), and runs the call. Successful settled transactions fire Triggers back to your app. Projects isolate one customer from another. Billing meters what settled.
That's the whole system. Everything else is framework-specific wiring or provider-specific fields.
Read the concepts in the order above the first time — each one builds on the previous. Skim back in any order after that.
Next steps
Last updated on
Multi-Tenant Agent
Build a SaaS where each customer runs their own commerce agent with their own providers and credentials. Sessions are scoped per tenant — isolated by design, metered per tenant for billing.
Sessions
Sessions are scoped connections to MCP servers that manage tool access, authentication, and usage tracking for AI agent commerce operations.