# Email-Based Payouts

Fuul supports sending rewards to users identified by email address — no wallet required at the time of conversion. This enables incentive programs for audiences that are not crypto-native.

## How it differs from other reward types

|                                    | Tokens (onchain) | Points (offchain)       | Email-based                 |
| ---------------------------------- | ---------------- | ----------------------- | --------------------------- |
| **User identifier**                | Wallet address   | Wallet address or email | Email address               |
| **Wallet required at conversion?** | Yes              | No (if using email)     | No                          |
| **Wallet required to claim?**      | Yes              | No                      | Yes (mapped later)          |
| **Distribution**                   | Onchain voucher  | Automatic               | Held until wallet is mapped |

## How it works

1. **User performs a qualifying action** — identified by their email address
2. **Fuul calculates the reward** — a pending payout is created with the email as the recipient
3. **Payout waits for wallet mapping** — it stays pending until a wallet address is mapped to the email
4. **Project creates an email-to-wallet mapping** — via the API or dashboard
5. **Rewards are resolved** — pending payouts are transferred to the mapped wallet address
6. **User claims** — the user can now claim their onchain rewards normally

## Setting up email-based payouts

Email-based payouts work with any trigger type. When sending custom events, use `email` as the `identifier_type`:

```json
{
  "name": "purchase_completed",
  "user": {
    "identifier": "user@example.com",
    "identifier_type": "email"
  },
  "dedup_id": "order-12345"
}
```

## Resolving email recipients

When rewards are created for email identifiers, they remain pending until you create a mapping. Use the recipient resolution endpoints to manage this:

Check which emails have pending payouts ([API reference](https://fuul.readme.io/reference/get_v1-payouts-pending-recipient-resolution)):

```typescript
// GET /v1/payouts/pending-recipient-resolution
// Returns: [{ email_identifier, pending_movements_count }]
```

Create mappings to resolve pending payouts to wallet addresses ([API reference](https://fuul.readme.io/reference/post_v1-payouts-recipient-mappings)):

```typescript
// POST /v1/payouts/recipient-mappings
// Body: {
//   mappings: [{
//     source_identifier: "user@example.com",
//     target_identifier: "0x1234...",
//     target_identifier_type: "evm_address"
//   }]
// }
```

{% hint style="info" %}
You can send up to 100 mappings per request. Once a mapping is created, pending payouts for that email are resolved to the target address.
{% endhint %}

## Use cases

| Use case                  | Description                                                                             |
| ------------------------- | --------------------------------------------------------------------------------------- |
| **Fintech & exchanges**   | Reward users who sign up or trade using their email, map wallets when they complete KYC |
| **CEX referral programs** | Track referrals by email, distribute token rewards after users create wallets           |
| **Pre-launch campaigns**  | Collect emails during waitlist phase, distribute rewards when users onboard             |
| **Non-crypto audiences**  | Run incentive programs for users who don't yet have wallets                             |

{% hint style="warning" %}
Email identifiers are normalized (lowercased) before processing. Ensure consistency when creating mappings.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.fuul.xyz/core-concepts/types-of-rewards/email-payouts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.