Skip to main content

Core Entities

Thiqwave organises money movement around a small set of objects. Understanding how they relate makes the rest of the API obvious.

Object map​

Partner (your company)
└── Application            ← one set of credentials per product/environment
    ├── Environment        ← TEST (sandbox) or LIVE (production)
    ├── Participant        ← the business/person you collect from or pay on behalf of
    │   ├── Beneficiary    ← a payout destination (bank account or wallet)
    │   └── Account        ← ledger-backed balances for this participant
    ├── Quote              ← a locked corridor + FX rate + fees (short TTL)
    │   └── Transaction    ← the money movement created from an accepted quote
    └── Webhook endpoint   ← where Thiqwave delivers signed event callbacks

Definitions​

EntityWhat it isCreated by
PartnerYour organisation on Thiqwave.Onboarding / invitation
ApplicationA logical grouping of credentials for one product or integration. Each application belongs to exactly one environment.Dashboard (or applications API)
EnvironmentTEST (sandbox, simulated money) or LIVE (production, real funds). Fully isolated — separate credentials, separate data.Tied to the application
ParticipantThe business or individual you are collecting from or paying on behalf of. Runs through KYB before money movement.POST /v1/participants
BeneficiaryA payout destination owned by a participant — a bank account, on-chain wallet, or mobile wallet.POST /v1/beneficiaries
AccountA ledger-backed balance for a participant and asset. Balances are read live from the platform ledger.Derived from transactions
CorridorA routable source→destination pair (e.g. AE-IN = AED in → INR out).Platform configuration
QuoteA locked corridor + FX rate + fee breakdown, valid for a short TTL (~2 min).POST /v1/transactions/quote
TransactionThe actual money movement, materialised from an accepted quote and a beneficiary. Stateful and idempotent.POST /v1/transactions
Webhook endpointYour HTTPS URL that receives signed event deliveries.POST /v1/webhooks

How they fit together (the happy path)​

  1. You hold an Application with a TEST or LIVE API key.
  2. Create a Participant (the sender). It passes KYB.
  3. Create a Beneficiary under that participant (the receiver).
  4. Request a Quote for the corridor (e.g. AE-IN, AED → INR).
  5. Accept the quote to lock the rate.
  6. Create a Transaction from the accepted quote + beneficiary.
  7. Subscribe a Webhook endpoint to receive settlement.completed.

IDs​

All entities expose stable external IDs (UUIDv7 / NanoID-style). Internal database IDs are never exposed. Always pass and store the external id.

Next​