Reap primary sources — 2026-04-30

Project status in this pass

• No canonical standalone whitepaper or litepaper surfaced.
• The clearest current source of truth is the official docs corpus and versioned API reference.

Primary-source snapshots

1) Docs introduction

• URL: https://docs.reap.global/introduction.md
• Key excerpt:
  • Reap describes itself as “Modular fintech infrastructure. Cards, wallets, compliance, and payments via a single API.”
  • The introduction says partners can launch card programs, onboard users with built-in compliance, accept stablecoin deposits across multiple chains, and track everything in a unified ledger.

2) Docs llms.txt

• URL: https://docs.reap.global/llms.txt
• Notes:
  • Enumerates a large first-party surface spanning accounts, cards, companies, crypto deposits, reconciliations, shipping, simulation, users, virtual assets, and webhook event types.
  • This was the fastest way to verify that Reap is a broad operating API rather than a single card or deposit feature.

3) Quickstart and API reference

• URLs:
  • https://docs.reap.global/quickstart
  • https://docs.reap.global/api-reference/introduction
• Key excerpt:
  • Reap uses a bearer-token REST API and requires a Reap-Version header (2025-02-14 in this pass).
  • The quickstart demonstrates sandbox API usage and user creation against https://sandbox.api.reap.global.

4) Accounts overview

• URL: https://docs.reap.global/accounts/overview
• Key excerpt:
  • An account is described as the unit of spending in Reap: every card is issued against an account, every authorization is evaluated against account balance, and every settlement clears debt on an account.
  • Balance is computed as availableBalance = assets - liabilities.
  • The docs distinguish Direct funding via stablecoin deposits from Prefund programs using allocated virtual assets.

5) Deposits guide

• URL: https://docs.reap.global/accounts/deposits
• Key excerpt:
  • Supported deposits move through PENDING → CONFIRMED → APPROVED, with webhooks at creation and each status change.
  • Unsupported assets are detected but do not count toward spending balance.
  • Sandbox testing requires real onchain testnet transfers rather than mock deposit simulation.

6) Supported assets

• URL: https://docs.reap.global/accounts/supported-assets
• Key excerpt:
  • Production support is explicitly documented for USDC and USDT on Ethereum and Solana.
  • Sandbox support is documented for Reap-issued test assets (RUSDC and RUSDT) on Ethereum Sepolia and Solana Devnet.
  • The docs say Reap is actively expanding supported chains and tokens.

7) Webhooks

• URL: https://docs.reap.global/webhooks/overview
• Key excerpt:
  • Reap sends signed HTTP POST webhooks with HMAC-SHA256 verification headers.
  • Non-2xx responses or timeouts retry with exponential backoff over roughly 48 hours.
  • Event types span user/company application status, crypto deposits, card status, account status, and card transaction lifecycle events.

8) Reconciliation endpoint

• URL: https://docs.reap.global/api-reference/reconciliations/reconcile-outstanding-card-debt
• Key excerpt:
  • Outstanding card debt can be cleared by burning specified virtual-asset balances held by the account.
  • This is strong evidence that Reap is operating a ledger/settlement layer, not merely a card-issuing frontend.

Working conclusion

Reap is best cataloged as modular fintech and stablecoin payments infrastructure: a card, wallet, compliance, ledger, and reconciliation control plane exposed through a unified API. In this pass, the docs corpus—not a whitepaper—was the real primary-source surface.