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

​
Endpoint coverage

​
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