Structure

This page shows how NadaPay's core resources relate to each other and how they are structured in the API — so you can reason about any endpoint before you call it.

Resource hierarchy

NadaPay has two parallel hierarchies that converge at the transaction layer:

The funding side — where money comes from:

Organization → Account → Wallet

The payout side — where money goes to:

Organization → Beneficiary → Beneficiary Account

The transaction — connects the two:

Wallet ──► [Quote] ──► Transaction ──► Beneficiary Account

Full relationship diagram

┌─────────────────────────────────────────────────────┐
│                    Organization                      │
│              (verified via KYC/KYB)                  │
└──────────────────────┬──────────────────────────────┘
                       │ owns
          ┌────────────┴────────────┐
          │                         │
    ┌─────▼──────┐           ┌──────▼──────┐
    │  Account   │           │ Beneficiary │
    └─────┬──────┘           └──────┬──────┘
          │ holds                   │ has
    ┌─────▼──────┐           ┌──────▼──────────────┐
    │   Wallet   │           │ Beneficiary Account  │
    │  (balance) │           │  (validated dest.)   │
    └─────┬──────┘           └──────┬───────────────┘
          │                         │
          └──────────┬──────────────┘
                     │
               ┌─────▼──────┐
               │    Quote   │
               └─────┬──────┘
                     │
               ┌─────▼──────┐
               │ Transaction │
               └────────────┘

How API endpoints map to this structure

NadaPay's API endpoints follow a consistent pattern based on the resource hierarchy:

Internal vs. external resources

NadaPay distinguishes between two types of resources:

When you execute a transaction, funds flow from an internal wallet to an external beneficiary account.

Child organizations

If you are a platform or partner team managing multiple business entities, NadaPay supports a parent-child organization model:

Parent Organization (your platform)
  └── Child Organization A  (your client)
  └── Child Organization B  (your client)
  └── Child Organization C  (your client)

Each child organization has its own accounts, wallets, beneficiaries, and transactions. As the parent, you can manage and monitor all child organizations under your API key.

📘

See Create a Child Organization and Fetch All Child Organizations in the API Reference.

What's next