Developers

One deterministic API surface for wallet operations and evidence.

Developers use Alloy to normalize wallet providers while preserving provider-native escape hatches and structured event receipts.

Join API design partners Read docs

API posture: The developer page should feel like a console and quickstart, not marketing decoration.

Decision matrix

The first integration should map to a real workflow.

Create a wallet operation, observe normalized state, and carry the receipt through downstream controls without hiding the provider reality developers need for debugging.

Operating boundary

Developer inputsBusiness refIdempotencyProvider targetPolicy context

Alloy API surfaceWalletKit intentLifecycle eventsReceiptsReplay

Provider realityNative IDsStatusCapabilitiesExceptions

Consumer systemsProductSupportFinanceCompliance

API surface

Start with the objects developers actually need.

The developer page frames the API around state, replay, evidence, and provider context rather than a generic SDK promise.

Transaction intent

The durable request object for wallet operations before provider submission.

RequiredBusiness reference

RequiredIdempotency key

ExplicitProvider target

AttachedPolicy context

Lifecycle event

Normalized state changes with enough source context for humans and systems.

NormalizedCanonical state

PreservedProvider-native ID

InspectableReason code

DesignedReplay support

Evidence receipt

The object that makes operations explainable after the workflow leaves the API call.

AttachedApproval trail

LinkedRisk outcome

Source-linkedProvider result

ExportableClose status

Developer promises

Small API surface, explicit provider reality.

Normalized objects

Wallet, address, transaction intent, policy decision, event, and receipt resources.

Provider context

Native IDs, provider status, unavailable capabilities, and raw reference links stay available for debugging.

Evidence-first events

State changes include business reference, reason, source, and downstream usefulness.

Idempotent operations

Retries should converge on deterministic intent and receipt state instead of duplicating money movement.

Lifecycle

The API should explain what happened without reading a provider console.

Intent

Business reference, asset, destination, provider target, policy context, and idempotency key.

State

Created, pending controls, approved, submitted, confirmed, failed, reversed, or reconciled.

Event

Webhook and polling updates normalized with source links and provider-native fields.

Receipt

Final evidence bundle for support, finance, compliance, and audit workflows.

Docs path

Developers should know where to go next.

Open path

Quickstart

Map one WalletKit transaction intent end to end before broad integration.

Open path

API reference

Review REST and typed service surfaces for WalletKit and adjacent modules.

Open path

Receipts

Inspect how evidence records should be shaped for review and replay.

Open path

Modules

Understand where PolicyKit, RiskGuard, ReconFlow, ShieldOS, VaultCore, TreasuryAI, and TokenForge attach.

Evidence

Proof the buyer can inspect.

Every route keeps Alloy's public story grounded in operating records, custody boundaries, and right-sized modules.

IdempotencyOperations are designed for retries and deterministic state.

Webhooks/eventsLifecycle changes are visible across systems with provider context preserved.

ReceiptsThe API story ends in support, finance, compliance, and audit evidence.

Docs pathReference docs remain crawlable and linked from the page.

Next step

Bring your current provider stack.

We will map the first workflow Alloy should stabilize, the custody boundary, and the modules that create evidence.

Join design partners

Prefer email? hello@alloy.build