Skip to main content
POST
cURL

Authorizations

Authorization
string
header
required

API token authentication using format <api token id>:<api client secret>

Headers

Grid-Wallet-Signature
string

Full API-key stamp built over the prior payloadToSign with the session API keypair of a verified authentication credential on the target internal account. Required on the signed retry; ignored on the initial call.

Request-Id
string

The requestId returned in a prior 202 response, echoed back exactly on the signed retry so the server can correlate it with the issued challenge. Required on the signed retry; must be paired with Grid-Wallet-Signature.

Path Parameters

id
string
required

The id of the internal account to export.

Body

application/json

Request body for POST /internal-accounts/{id}/export. The clientPublicKey is required on both steps of the signed-retry flow. On step 1 Grid binds it into payloadToSign so the subsequent stamp in Grid-Wallet-Signature commits to the target pubkey; on step 2 the client echoes the same clientPublicKey back and Grid uses it to encrypt the wallet credentials returned in the 200 response.

clientPublicKey
string
required

Fresh P-256 public key, uncompressed SEC1 hex — 130 hex chars where the first two are 04 (the uncompressed-point indicator). Generate a new keypair for each export and discard the private key after decrypting the response.

Example:

"04f45f2a22c908b9ce09a7150e514afd24627c401c38a4afc164e1ea783adaaa31d4245acfb88c2ebd42b47628d63ecabf345484f0a9f665b63c54c897d5578be2"

Response

Signed retry accepted. Returns the encrypted wallet credentials (InternalAccountExportResponse); or, when the underlying wallet-provider activity is still in flight, a WalletOperationProcessing body with status: "PROCESSING" — the credentials are never stored server-side, so the client re-sends the byte-identical signed retry to collect them once the activity settles. The challenge stays usable until an attempt actually returns credentials.

Response body for the signed retry of POST /internal-accounts/{internalAccountId}/export. Normally an InternalAccountExportResponse — the encrypted wallet credentials. When the underlying wallet-provider activity is still in flight, this is instead a WalletOperationProcessing body with status: "PROCESSING". The credentials are never stored server-side, so re-sending the byte-identical signed retry is how they are collected: the re-send returns them as soon as the activity has settled, and the challenge is consumed only by the attempt that delivers them.

id
string
required

The id of the internal account that was exported.

Example:

"InternalAccount:019542f5-b3e7-1d02-0000-000000000002"

encryptedWalletCredentials
string
required

Encrypted wallet mnemonic, sealed to the clientPublicKey from the request body using HPKE: DHKEM(P-256, HKDF-SHA256) + HKDF-SHA256 + AES-256-GCM. Decrypt with the matching private key, then manage the mnemonic securely because it is the master key of the self-custodial Embedded Wallet. The value is a JSON string of the form {"version": "v1.0.0", "data": "<hex>", "dataSignature": "<hex>", "enclaveQuorumPublic": "<hex>"}. data hex-decodes to JSON {"encappedPublic": "<hex>", "ciphertext": "<hex>", "organizationId": "<id>"}, where encappedPublic is the uncompressed SEC1 ephemeral public key. dataSignature is an ECDSA-P256-SHA256 signature over the data bytes produced by the issuer key in enclaveQuorumPublic; verify before decrypting. In sandbox, dataSignature and enclaveQuorumPublic are empty strings. Clients should bypass attestation verification when calling against sandbox.

Example:

"{\"version\":\"v1.0.0\",\"data\":\"7b22656e6361707065645075626c6963223a22303433...\",\"dataSignature\":\"3045022100c9...\",\"enclaveQuorumPublic\":\"04a1b2c3...\"}"