> ## 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.

# Signing Endpoints

> Wallet management, transaction prepare/confirm, passkeys, recovery, policies, and approval flows

<Warning>
  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.
</Warning>

Reference for Signing Kit endpoints. For interactive schemas and try-it functionality, see the [API Reference](/api-reference/introduction).

## 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):**

```json theme={null}
{
  "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
```

<Note>
  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.
</Note>

***

### 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}
```

<Warning>
  Cancellation is only possible before the transaction has been broadcast. Once it is in the mempool, this endpoint cannot reverse it.
</Warning>

***

## 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:**

```json theme={null}
{
  "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):**

```json theme={null}
{
  "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):**

```json theme={null}
{
  "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](/api-reference/introduction). Signing Kit endpoints are grouped under **Wallets**, **Transactions**, **Passkeys**, **Recovery**, **Signing Approvals**, and **Signing Policies**.