> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluz.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Register & Send
> Register a recipient's identity and billing address up front with registerUser, then generate a hosted virtual card link bound to that known user with generateVCShareLinks (shareMethod: EXISTING_USER). Unlike the standard flow, the card is created at link-generation time, not at claim.
The [standard hosted-link flow](/features/open-loop-cards/send-open-loop-cards) 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.
| Operation | Scope | Also required |
| ---------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `registerUser` | — | Registration permission enabled on your application |
| `generateVCShareLinks` | `CREATE_SHARE_LINK` | An active virtual card offer, a spend account to fund from (optionally with prepayment/rewards balance as fallback) |
**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](/concepts/authentication) for how to mint a scoped token.
[Demo open loop cards](https://demos.fluz.app/card-issuing/?launch-card=1)
## How this differs from the standard flow
| | Standard (`GENERATE_URL` / `EMAIL` / `PHONE_NUMBER`) | This flow (`EXISTING_USER`) |
| ----------------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------------- |
| Recipient identified by | Email / phone in `recipientListEmail` / `recipientListPhone` | Known Fluz `userId` in `recipientUserIds` |
| Card created | At claim, when the recipient completes onboarding | At `generateVCShareLinks` call time |
| Card funded | At claim time | At claim time (same as standard) |
| Who can claim the link | Whoever opens it first, if unclaimed | Only the assigned recipient — enforced from the moment the link is created |
| Recipient onboarding at claim | Sign-in, 2FA, billing address (if needed) | Sign-in, 2FA — no billing address prompt, since it was collected at registration |
| Revealing the card | Prompts for PIN (or PIN creation, if none set yet) | Prompts for PIN (or PIN creation, if none set yet) |
See [Send Open Loop Cards](/features/open-loop-cards/send-open-loop-cards) for the standard flow and [Recipient Experience](/features/open-loop-cards/open-loop-cards-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](/deploying-to-production).
* **Never register real people in staging.** See [Staging vs. Live](/concepts/environments).
## Next steps
The standard flow — generate links and let Fluz issue the card at claim time.
What the recipient sees when they open and claim a hosted link.
Full reference for `registerUser`, including error handling and fallback patterns.