Skip to main content
Para’s REST API lets your backend create wallets and sign over HTTP. Two interfaces sit on top of the same API. Pick the one that fits your stack:

REST SDK — @getpara/rest-sdk

Raw HTTP API

Try it in the API referenceDownload OpenAPI Spec

​
Prerequisites

To use Para REST, you need an API key. It authenticates every request through the X-API-Key header.
Don’t have an API key yet? Request access to the Developer Portal to create API keys, manage billing, teams, and more.
You can restrict Para REST to specific IPs by adding CIDR entries in the Developer Portal. Once you add them, requests from other IPs return 401 Unauthorized.
Protect your API key. REST API wallets are permanently scoped to the project that created them. If you lose access to your API key, you can rotate it safely. Deleting the project or creating a new one means losing wallet access. See Setup → Authentication for details.

​
When to Use

  • Programmatic wallets: the default path for new server-created or pre-created wallet integrations.
  • Any secp256k1 or ed25519 chain: the sign-raw endpoint is chain-agnostic. Create an EVM wallet for secp256k1 signing (works with Bitcoin, etc.) or a Solana/Stellar wallet for ed25519 signing, then hash and serialize transactions on your side.
  • Your backend needs wallets and you prefer REST semantics over share-backed SDK ceremonies.
  • You already rely on secret-key auth + IP allowlists.
  • You prefer cURL or language-native HTTP clients over SDKs.

​
Wallet lifecycle

REST-created wallets are pre-created wallets. The difference is the integration surface: REST creates and signs through HTTP, while SDK pregen creates wallets through SDK share-management flows.
PhaseREST behavior
CreateYour backend calls POST /v1/wallets with type, userIdentifier, and userIdentifierType.
Sign before claimYour backend signs with REST while the wallet is still project-controlled.
Track broadcaststransfer and sign-transaction with broadcast: true return transactionId for polling or webhooks.
ClaimA user can claim the wallet through a client SDK flow if the identifier matches.
After claimREST signing stops because the wallet is now user-owned. Use client SDK flows instead.

​
Endpoint coverage

EndpointEVMSolanaCosmosStellarNotes
POST /v1/walletsYesYesYesYesCreates a project-controlled wallet.
sign-rawYesYesYesYesSigns raw hex bytes.
sign-messageYesYesYesYesEVM uses EIP-191. Other wallet types sign UTF-8 bytes.
sign-transactionYesYesNoYesEVM and Solana can broadcast with broadcast: true. Stellar is sign-only.
sign-typed-dataYesNoNoNoEIP-712 only.
sign-authorizationYesNoNoNoEIP-7702 only.
transfer and estimate-feeYesYesNoNoBuilds transfer transactions for supported chains.

​
Wallet Claiming

When a user signs up through your app with the same identifier used to create the wallet (e.g., the same email), the wallet is automatically claimed and transferred to their account. No server-side action is needed. For details on the client-side flow, see the Web Pregeneration guide.

​
Next Steps

REST SDK

Setup

BYO auth

Multi-Wallet Setup

Migrate from SDK Pregen

Raw HTTP Example