Complete client reference

The reference covers every method in the documented shared client contract. Each domain page lists the method name, HTTP route, base access requirement, availability, input fields, and expandable structural input/output schemas. The snapshot is generated from application revision 1c90c5e. It contains 135 core methods, 4 optional Aurora methods, and 50 designed methods. Check the live endpoint registry and optional provider configuration before relying on current availability.

Identity and accounts

Authentication, account settings, wallets, passkeys, sessions, and notifications.

Commerce

Merchants, product assets, campaign drafts, policies, and studio tools.

Distribution

Links, ancestry, network views, public profiles, and reputation.

Settlement

Checkout, delivery, receipts, earnings, vaults, reports, and refund requests.

Funding and insights

Gas assistance, separate optional mainnet funding, and cached wallet context.

Platform

Networks, tokens, health, support, developer, and operator surfaces.

Designed extension methods complete the catalog for partnerships, invitations, communities, integrations, billing, subscriptions, teams, and other extension domains. Their inclusion documents the client design; it does not activate their live implementation.

How to read a method

Client input is the object passed to the typed method. Path fields move into the URL; some methods unwrap a nested body, and uploads use multipart. Read HTTP transport before forming a raw request. Output is the successful response’s data field. It is wrapped by the standard envelope described in API overview. Access is the shared route’s base requirement. Session access does not imply permission to read another account’s records, act as a merchant, perform operator actions, or skip a fresh confirmation. Service authorization still applies. Availability distinguishes core routes, conditional optional funding, and designed routes that return FEATURE_NOT_AVAILABLE. A core service may still need configuration or have no data for a given account.

Schema fidelity

The JSON schemas are generated structural projections of the original Zod schemas. They describe fields, shapes, enums, and representable bounds. They do not reproduce every custom refinement, transform, byte-range check, browser file validator, business rule, or runtime authorization check. For example, weights must sum to 10,000, a canonical integer must fit its onchain range, an HTTPS-only URL refinement must pass, and some confirmation purposes require an action name. Those validations remain in the shared Zod/server implementation even when a JSON Schema projection cannot express them completely. The client contract is shared with Demo mode, so some structural ID unions include demo-…. Live services still require live IDs and enforce their own boundaries. Do not use these projections to bypass the original validator. Download the complete method snapshot · Download the error code union · Read the original schemas Source-definition links point into the application repository and require repository access. The schema downloads and this documentation are public.

Updating the reference

The docs repository includes scripts/generate-api-reference.mts. Run it with the Spoke workspace’s installed tsx loader and the desired source checkout. It records the exact Git revision and regenerates method pages, schema downloads, and the contract event reference. Review availability and explanatory prose when the source contract changes. Generated schemas are reference material, not a public promise that future incompatible changes will be silently accepted. Consumers should pin an intended contract/version and validate responses.