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.

Operating boundary

Customer systems Product flowsFinance closeCompliance review

Alloy control plane WalletKitPolicyKitRiskGuardReconFlow

Execution boundary Custody providersCustomer cloudAudit evidence

Developer promises

Small API surface, explicit provider reality.

Normalized objects

Wallet, address, transaction, policy, and receipt resources.

Provider context

Native IDs and status stay available for debugging.

Evidence-first events

State changes are useful to humans and machines.

Evidence

Proof the buyer can inspect.

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

Idempotency Operations are designed for retries and deterministic state.

Webhooks/events Lifecycle changes are visible across systems.

Docs path Reference docs remain crawlable and linked.

API preview

A request should already look operational.

The first developer touchpoint shows business reference, idempotency, provider target, and evidence intent.

POST /v1/walletkit/transaction-intents
{
  "business_ref": "payout_42819",
  "asset": "USDC",
  "provider_target": "fireblocks",
  "policy_context": "stablecoin_payouts",
  "idempotency_key": "intent_01HY..."
}

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