QwikLive Onboarding API
The administrative API for onboarding and configuring financial institutions, users, roles, core connectivity and terminals on the QwikLive platform — one consistent, versioned REST interface.
Overview
For developers, architects, testers, support teams and client integration teams who build against or operate the QwikLive Onboarding service.
Where the underlying source does not specify a value, type, or business rule, it is explicitly marked To be confirmed. All examples use synthetic, masked data — never paste real credentials or tokens into shared environments.
Introduction
The QwikLive Onboarding API is a versioned REST service (current version v1) that centralizes the configuration and lifecycle management of the entities a financial-services platform needs before it can process transactions. Through a single, consistent interface you can onboard a financial institution, wire it to a core banking system, define which account types and transactions it supports, register terminals, and manage the users and roles that administer it.
Requests and responses are JSON over HTTPS. Most write operations are protected by a bearer (JWT) access token, and every entity supports soft activation/deactivation rather than hard deletion.
Business Purpose
Onboarding a bank or credit union onto a transaction-processing platform involves many interdependent configuration steps. This API exists to make that process:
- Self-service & auditable — every entity has a
createdBy/modifiedBytrail and an enabled/disabled state. - Consistent — a uniform response envelope, pagination model and activation pattern across all resources.
- Secure by default — JWT authentication, optional MFA/OTP, and encryption of sensitive credentials in transit.
- Multi-tenant — enterprise tenants can manage sub-tenants and scope roles per tenant.
Key Capabilities
High-Level Architecture
Clients call the Onboarding API through an API gateway. The service persists configuration, brokers authentication, and delegates to downstream microservices and core banking systems.
┌─────────────────────────┐
│ Client / Admin Portal │
│ (UI, scripts, Postman) │
└────────────┬────────────┘
│ HTTPS + Bearer JWT
▼
┌─────────────────────────┐
│ API Gateway │ x-correlation-id propagated
└────────────┬────────────┘
▼
┌─────────────────────────┐ ┌──────────────────────┐
│ QwikLive Onboarding │ ─────▶ │ Auth / MFA / OTP │
│ Service (/v1/...) │ └──────────────────────┘
│ │ ┌──────────────────────┐
│ • FIs, Account Types │ ─────▶ │ Configuration store │
│ • Roles / Modules │ └──────────────────────┘
│ • Core Connectivity │ ┌──────────────────────┐
│ • Terminals, Tenants │ ─────▶ │ Core banking systems │
└────────────┬────────────┘ └──────────────────────┘
▼
┌─────────────────────────┐
│ Other QL microservices │ (health, dashboard, channels)
└─────────────────────────┘
The internal component boundaries above are a representative model based on the observed endpoints. The precise deployment topology and canonical per-environment hostnames are To be confirmed with the platform team.
Typical Integration Flow
A first-time integration usually follows this order:
Authenticate
Obtain a JWT via POST /v1/onboarding/login/user (complete MFA/OTP if required).
Onboard the financial institution
POST /v1/onboarding/financialInstitution — register the FI with BIN, core name and API type.
Configure core connectivity
POST /v1/onboarding/core-connectivity/data — host, port, service paths and credentials.
Define account types & capabilities
POST /v1/onboarding/account-types, then POST /v1/onboarding/transaction-capabilities.
Register terminals
POST /v1/terminal-key — app/terminal keys per financial institution.
Create roles & users
POST /v1/onboarding/roles, then POST /v1/onboarding/users — assign RBAC.
Verify & monitor
Query transactions, dashboard statistics and service health.
See the complete "onboard a new bank" scenario in Recipes / Use Cases, which chains these calls into a single flow.