Para’s REST API provides a simple HTTP surface for creating wallets and signing from your backend. Use
@getpara/rest-sdk when you want typed TypeScript methods and signer adapters; use the raw HTTP API when you want
language-native fetch or cURL.Download OpenAPI Spec
To use Para, you need an API key. This key authenticates your requests to Para services and is essential for
integration.
Don’t have an API key yet? Request access to the 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.
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.
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.
Phase
REST behavior
Create
Your backend calls POST /v1/wallets with type, userIdentifier, and userIdentifierType.
Sign before claim
Your backend signs with REST while the wallet is still project-controlled.
Track broadcasts
transfer and sign-transaction with broadcast: true return transactionId for polling or webhooks.
Claim
A user can claim the wallet through a client SDK flow if the identifier matches.
After claim
REST signing stops because the wallet is now user-owned. Use client SDK flows instead.
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.
