Skip to main content

Route Families

Ikawaari currently exposes multiple implemented API families rather than a single perfectly uniform namespace.

This page explains how to read the platform API surface correctly.

Why route families matter​

Different capabilities are exposed through different route groups, depending on whether the caller is:

  • a server-to-server integration using API keys
  • a merchant-authenticated dashboard or merchant client
  • a checkout session or hosted checkout flow
  • a module-specific integration such as escrow, billing, or marketplace

Core route families​

Public or API-key oriented resources​

Examples include route families such as:

  • payment_intents
  • webhook_endpoints
  • balance
  • balance_transactions

These routes are important for payment and event-driven integrations.

Merchant route family​

Merchant operational capabilities are primarily exposed under:

  • api/v1/merchant/*
  • api/merchant/*

This family includes dashboard, payments, balance, payouts, reporting, notifications, settings, search, and other merchant operations.

Checkout route families​

Checkout-related functionality is split between:

  • api/v1/checkout/sessions
  • api/checkout/*

These are used for session creation, hosted checkout flows, payment submission, status polling, and receipts.

Product and module route families​

Implemented domains also have dedicated route groups, including:

  • api/v1/escrow/*
  • api/v1/billing/*
  • api/v1/marketplace/*
  • api/v1/payout-engine/*
  • api/v1/funding/*

Documentation rule​

The Ikawaari docs should document the implemented API shape as it exists today, even when it spans multiple route families.

The goal is to be exact first, then progressively improve consistency or generated reference coverage over time.