One API to connect African markets

Build on the Inopay infrastructure: unified KYC, order routing, cross-SGI portability, real-time quotes. OpenAPI 3.1 docs, signed webhooks, public sandbox, and test keys in 2 minutes.

Self-serve API keys · OpenAPI 3.1 · HMAC-SHA256 webhooks · Ed25519 signature public key
Core endpoints

Three surfaces, one API

The Inopay API is organised around three complementary products. You can use KYC only, use order routing only, or combine them all.

Unified KYC

POST/v1/kyc/sessions
GET/v1/kyc/:id
GET/v1/kyc/by-email/:email
POST/v1/kyc/:id/request-portability
POST/v1/kyc/:id/complement
POST/v1/kyc/:id/revoke
GET/v1/kyc/:id/audit-trail
POST/v1/kyc/verify-attestation

Orders & portfolios

GET/v1/orders
POST/v1/orders
GET/v1/orders/:id
GET/v1/portfolio
GET/v1/instruments
GET/v1/calendar
GET/v1/clients
Quickstart

Your first call in 2 minutes

Authenticate with a Bearer key, call the KYC session creation endpoint, and receive a hosted URL to send to your investor.

# Create a KYC session for a diaspora investor
curl -X POST https://api.getinopay.com/v1/kyc/sessions \
  -H "Authorization: Bearer inopay_test_abc123..." \
  -H "Content-Type: application/json" \
  -d '{
    "email": "amadou@example.com",
    "full_name": "Amadou Diallo",
    "phone": "+33612345678",
    "requested_level": "KYC2"
  }'

# Response (HTTP 201)
{
  "ok": true,
  "data": {
    "profile_id": "7b2f1a...",
    "hosted_url": "https://getinopay.com/kyc/start?profile=...&t=...",
    "session_expires_in": 3600,
    "sandbox": true
  }
}
Technical principles

What never changes

Versioned OpenAPI 3.1

The /v1/ spec is frozen. v1.x evolutions are backwards-compatible; v2 ships with 180 days' notice and 12 months of coexistence.

HMAC-SHA256 webhooks

Every outgoing event is signed with your shared secret. The X-Inopay-Signature: t=...,v1=... header is verifiable in 3 lines.

Offline Ed25519

KYC attestations are signed with an Inopay Ed25519 key published at /.well-known/inopay-kyc-pubkey.pem, verifiable with no network call.

Idempotency

Every mutating request accepts an Idempotency-Key header. Replaying a request with the same key returns the original response.

Transparent rate limiting

1,000 req/min per SGI key by default. The X-RateLimit-* headers give you the remaining budget in real time.

Indistinguishable sandbox

Keys inopay_test_* vs inopay_live_*. Same behaviour, same latency, mock data. Production migration = swap the key.

Resources

Everything you need

Get your sandbox keys

Self-serve test keys, no intro call required. Production activates once the SGI pilot agreement is signed.

Request my sandbox keys Read the full spec