Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.relayer.fi/llms.txt

Use this file to discover all available pages before exploring further.

All signing and broadcast operations interact with live blockchain networks. Transactions are irreversible once broadcast. Verify destination addresses and amounts carefully before calling any broadcast endpoint.
Reference for Signing Kit endpoints. For interactive schemas and try-it functionality, see the API Reference.

How signing works

Every signing operation uses a two-step prepare/confirm flow so private key material never leaves the secure enclave:
  1. Prepare — the API returns an unsigned activity (for wallet creation) or an unsigned transaction (for signing).
  2. Stamp — the client stamps the payload with a registered passkey (WebAuthn, browser-side).
  3. Confirm — the API validates the stamped payload, processes it inside the enclave, and persists / broadcasts the result.
The same pattern applies to wallet creation, address creation, and transaction signing.

Wallets

Prepare wallet creation

Build an unsigned wallet-creation activity. The response contains the payload to stamp with a passkey on the client.
POST /v1/signing/wallets/prepare

Confirm wallet creation

Submit the passkey-stamped activity. The signing enclave processes it and returns the persisted wallet.
POST /v1/signing/wallets/confirm
Response (shape):
{
  "success": true,
  "data": {
    "walletId": "wallet_abc123",
    "name": "My Wallet",
    "createdAt": "2026-03-28T12:00:00.000Z"
  }
}

List wallets

GET /v1/signing/wallets

Get wallet

GET /v1/signing/wallets/{walletId}

Prepare wallet accounts (addresses)

Build an unsigned CREATE_WALLET_ACCOUNTS activity.
POST /v1/signing/wallets/accounts/prepare

Confirm wallet accounts (addresses)

Submit the passkey-stamped activity. Generates new addresses derived from the wallet’s root key.
POST /v1/signing/wallets/accounts/confirm

Get wallet addresses

GET /v1/signing/wallets/{walletId}/addresses
GET /v1/signing/wallets/{walletId}/addresses/{addressId}

Get wallet transactions and denials

GET /v1/signing/wallets/{walletId}/transactions
GET /v1/signing/wallets/{walletId}/denials

Transactions

Prepare a transaction

Build an unsigned transaction and store it with awaiting_signature status. The client signs the returned unsigned hex with the user’s passkey and submits via confirm.
POST /v1/transactions/prepare

Confirm a prepared transaction

Submit the signed transaction hex. The API validates the signature against the original unsigned transaction via hash comparison, persists the signed transaction, and broadcasts to the blockchain.
POST /v1/transactions/confirm
Confirm broadcasts the transaction by default. If you need to gate the broadcast separately (multi-step approval, scheduled submission), use the broadcast endpoints below with a transaction prepared via the same flow.

List transactions

GET /v1/transactions/sign                       — All signed transactions
GET /v1/transactions/sign/{transactionId}       — One signed transaction
GET /v1/transactions/pending-signature          — Transactions awaiting passkey signature

Cancel a pending transaction

Cancel a transaction in awaiting_signature status (before passkey stamping).
DELETE /v1/transactions/sign/{transactionId}
Cancellation is only possible before the transaction has been broadcast. Once it is in the mempool, this endpoint cannot reverse it.

Broadcasting

Broadcast a signed transaction

Submit a previously signed transaction to the blockchain. Use this when you want to gate the broadcast step separately from confirm.
POST /v1/transactions/broadcast/{transactionId}
Response:
{
  "success": true,
  "data": {
    "transactionId": "tx_def456",
    "txHash": "0xabc...def",
    "status": "broadcast",
    "network": "sepolia"
  }
}

Broadcast a raw signed transaction

Submit a pre-signed raw transaction payload — useful when you have an externally-signed transaction.
POST /v1/transactions/broadcast/raw

Get broadcast status

GET /v1/transactions/broadcast/{transactionId}
Status values: broadcast, confirmed, failed

Retry a failed broadcast

POST /v1/transactions/broadcast/{transactionId}/retry

Passkeys

Passkeys are WebAuthn credentials registered to a wallet workspace. They authorize every signing operation.

Generate a challenge

POST /v1/signing/passkeys/challenge

Register a passkey (creates the wallet workspace)

POST /v1/signing/passkeys/register

Add a passkey to an existing workspace

POST /v1/signing/passkeys/add

List passkeys

GET /v1/signing/passkeys

Rename / delete passkey

PATCH  /v1/signing/passkeys/{id}     — Rename
DELETE /v1/signing/passkeys/{id}     — Delete

Recovery

If a user loses access to their passkey, recovery re-binds a new passkey to the existing wallet without rotating the underlying keys.
POST /v1/signing/recovery/initiate              — Start email-based recovery
POST /v1/signing/recovery/sync                  — Sync FE-completed recovery passkey
GET  /v1/signing/recovery/context               — Recovery context for the iframe flow
GET  /v1/signing/recovery/migration-eligibility — Check whether the wallet can migrate

Signing Policies

Signing policies restrict which transactions a wallet will sign. Policies are enforced inside the signing enclave, before any transaction is processed.

List policies

GET /v1/signing/policies

Create a policy

POST /v1/signing/policies
Request body (example):
{
  "name": "Max transfer limit",
  "walletId": "wallet_abc123",
  "rules": {
    "maxValueUsd": 10000,
    "allowedDestinations": ["0xApprovedAddress1", "0xApprovedAddress2"]
  }
}

Update / delete a policy

PATCH  /v1/signing/policies/{id}
DELETE /v1/signing/policies/{id}

Approval Flows

Require human approval for transactions above a threshold before the signing enclave processes them.

Get / update approval config

GET   /v1/signing/approval-config
PATCH /v1/signing/approval-config
Update body (example):
{
  "enabled": true,
  "thresholdUsd": 5000,
  "requiredApprovers": 1
}

List pending approvals

GET /v1/signing/approvals

Approve a request

POST /v1/signing/approvals/{id}/approve
POST /v1/signing/approvals/{id}/approve-with-passkey
Use /approve-with-passkey when the approval itself must be passkey-stamped (the default for agent transaction approvals).

Reject a request

POST /v1/signing/approvals/{id}/reject

Key Rotation

To rotate keys for a wallet, generate a new address from the same wallet using the prepare/confirm accounts flow. The new address has a new derived key while the wallet root key remains unchanged inside the secure enclave. For workspace-level API key rotation, generate a new key from the dashboard and revoke the old one.

Full API Reference

All endpoints include interactive schemas and a try-it playground in the API Reference. Signing Kit endpoints are grouped under Wallets, Transactions, Passkeys, Recovery, Signing Approvals, and Signing Policies.