Skip to main content
The standard hosted-link flow defers everything to the recipient: you mint a link, and Fluz doesn’t create the virtual card until the recipient opens it, verifies themselves, and claims it. This flow inverts that for recipients you’ve already identified. You register the recipient’s identity and billing address yourself with registerUser, then generate a share link with generateVCShareLinks using shareMethod: EXISTING_USER. Fluz creates the virtual card immediately, at generation time — not at claim — and binds it to that one recipient. The link is still delivered and claimed the normal way; only card creation moves earlier. Funding is still drawn at claim time, same as the standard flow — from userCashBalanceId, falling back to your prepayment or rewards balance if enabled and the spend account runs short.
When to use this instead of a plain share link
  • You already know exactly who the recipient is (by user ID) and want the card created and ready before you notify them, rather than waiting on them to claim it.
  • You want a hard guarantee that only the intended recipient can ever view the link — not “first person to click it.”
  • You’re sending to a batch of known recipients and want deterministic 1:1 mapping between recipient and card.

​
Before you start

You’ll need a Bearer access token. Basic auth is not accepted for either operation.
User registration is not enabled by default. registerUser is a restricted mutation — your application must be explicitly approved by Fluz before it can create users. Contact your Fluz sales rep or account manager to have it enabled. Calls from an unapproved application fail with AUTH-0022.If the recipient already has a Fluz account, you can skip registration and go straight to generateVCShareLinks with their existing recipientUserIds.
See Authentication for how to mint a scoped token. Demo open loop cards

​
How this differs from the standard flow

See Send Open Loop Cards for the standard flow and Recipient Experience for the full claim walkthrough.

​
Notes and limitations

  • recipientUserIds must reference existing Fluz users. If the recipient isn’t registered yet, register them first with registerUser (this flow), or use the standard hosted-link flow and let Fluz onboard them at claim time.
  • recipientUserIds length must equal quantity. A mismatch returns a validation error and creates no records.
  • Card creation moves to generation time — funding does not. The virtual card object and recipient binding are created when you call generateVCShareLinks, but funds are still drawn at claim time, same as the standard flow: from userCashBalanceId first, then your prepayment or rewards balance as a fallback if usePrepaymentBalance / useRewardsBalance are set and the spend account is insufficient.
  • Registration is per-application and per-environment. Permission granted for staging does not carry to production. See Deploying to Production.
  • Never register real people in staging. See Staging vs. Live.

​
Next steps

Send Open Loop Cards

The standard flow — generate links and let Fluz issue the card at claim time.

Recipient Experience

What the recipient sees when they open and claim a hosted link.

Register Customers

Full reference for registerUser, including error handling and fallback patterns.