Claim non-custodial control for a customer
Initiates a multi-signer non-custodial provisioning flow. Returns 202 with a claimId; per-signer verification URLs are delivered via wallet_signer.invited webhooks.
A business customer’s roster has exactly 2 admins (400 ROSTER_BELOW_MIN_ADMINS with fewer, 400 ROSTER_ABOVE_MAX_ADMINS with more); every other member is a signer. An individual customer’s roster has exactly one admin and at most one person. The person is the member under the individual’s email on file, with credentialType: "passkey", and must be the admin; every other member is an api_key member with role: "signer". With no person, which only programmatic unattended allows, the admin is one api_key member. Any other roster returns 422 INDIVIDUAL_ROSTER_INVALID, and so does a later add of a passkey member or an admin, or a promote to admin. Unlike a business, an individual’s roster cannot have the person and an api_key admin together. The person enrolls two passkeys (for example on two devices) before the wallet activates, so one lost device does not lose the funds. Conduit can never sign or change the wallet alone.
Valid roster shapes depend on the customer’s signing mode, which Conduit sets per organization (with an optional per-customer override) — confirm the customer’s configured mode before building the roster: passkey required — any api_key member returns 422 SIGNING_MODE_ROSTER_INVALID; programmatic — api_key members must have role: "signer" (an api_key admin returns 422 SIGNING_MODE_ROSTER_INVALID); programmatic unattended — api_key admins are allowed. In every mode the active signers of any credential type must be able to reach signingThreshold; passkeys count toward it. Each api_key member carries a publicKey — the compressed public key, 33 bytes / 66 hex chars, 02/03 prefix, on the curve of its signatureScheme (p256 by default, or secp256k1 / secp256k1_eip191) — and is active at claim — an all-machine roster activates the wallets without an enrollment phase; mixed rosters wait on every passkey enrollment. Omitting chains provisions the default set: base, ethereum, polygon, tron. A default chain that does not settle in the environment is left out. A chain whose addresses need a one-time on-chain setup is not in the default set: name it in chains. Its wallet reads pending until the signers approve that setup, announced by wallet.awaiting_setup_signature. See Programmatic payout signing and Add a crypto wallet.
Authorizations
Headers
Caller-generated unique key that lets the server safely replay this request. The original response is returned for 30 days on any retry with the same key from the same organization, with the response header Idempotency-Replayed: true. Required on every state-changing money-moving or resource-creating POST.
1 - 128^[A-Za-z0-9_.:-]{1,128}$"01J7B3K2X9M8N5P6Q7R8S9T0V1"
Path Parameters
"cus_1A2b3C4d5E6f7G8h9I0jKl"
Body
Everyone who will be able to approve on this wallet. Each member activates their own signer afterwards. A business customer's roster has exactly 2 admins. An individual customer's roster has exactly one admin and at most one person: the person is the member under the individual's email on file, with credentialType: passkey, is the admin, and enrolls two passkeys before the wallet activates; every other member is an api_key signer. Under programmatic unattended the roster can instead be one api_key admin and api_key signers.
1 - 100 elementsHow many roster members must approve before a transaction is signed. At least 1, and never more than the roster size.
1 <= x <= 9007199254740991Optional. Chains to provision (each must be a supported chain). Omit to auto-provision each default chain that settles in this environment (recommended) so later chain use needs no re-authentication. Accepting a chain here does not imply Conduit operationally supports asset movement on it yet.
1 - 100 elementsethereum, base, solana, polygon, tron, stellar, tempo, arbitrum Response
Id of this claim, carried by the webhooks that report its progress. Each id has the form wcc_ followed by 22 alphanumeric characters.
^wcc_[0-9A-Za-z]{22}$Customer the wallets are provisioned for. Each id has the form cus_ followed by 22 alphanumeric characters.
^cus_[0-9A-Za-z]{22}$Always provisioning: the claim was accepted and the wallets are being set up in the background. Wait for the wallet_signer.* and crypto_wallet.completed webhooks.
provisioning How many signers the claim put on the roster.
0 <= x <= 9007199254740991How many signer stamps each payout needs to proceed. Separate from activation, which waits for every roster member to enroll.
0 < x <= 9007199254740991Advisory estimate of minutes to full activation (not an SLA).
-9007199254740991 <= x <= 9007199254740991