Choose a KYC Method

Reap supports three integration methods. The relevant one for integration depends on which method your business qualified for and on what you signed up for within the CaaS contract.

Authentication

All Reap Compliance API requests require an API key passed as a request header:

x-reap-api-key: 

Retrieve your API keys from: Reap Dashboard → Settings → Product Settings → KYC API Keys

Always build and test your integration against Sandbox before switching to Production keys.

Key Concepts

These terms appear throughout the API documentation. Familiarising yourself with them before starting will make the integration guides easier to follow.

Business

Your organisation as registered with Reap. Identified by a unique API Key and Business UUID (BUUID). All entities, requirements, and KYC activity are scoped to your BUUID.

Entity

The individual being verified. Every user who goes through KYC is represented as an entity in Reap's system.

When you create an entity, Reap assigns it a unique entityId. You can also pass your own internal user identifier as externalId to link the entity back to your system.

{
  "entityId": "ent_123e4567-e89b-12d3-a456-426614174000",  // assigned by Reap
  "externalId": "user_123"                                  // your internal ID
}

All three KYC methods support INDIVIDUAL entities.

Feature

A capability that has been enabled for your business. For KYC, the relevant feature is Card Issuance — the authorisation to verify users and issue them payment cards. Features must be enabled by Reap before they can be used.

Requirements

The documents and checks a user must complete to become eligible for a Feature. Each requirement is identified by a requirement slug — a string identifier used in API calls to reference a specific check.

The requirements differ by KYC method:

Status

Every entity and requirement has a status reflecting where it is in the KYC process. Statuses are delivered via webhook notifications rather than requiring you to poll.

Signed Payload

Once an entity is approved, you retrieve a signed payload from Reap. This is a cryptographically signed object that proves the entity passed KYC and authorises card creation. It is passed directly into the CaaS POST /cards request.

The signed payload is method-specific:

• KYCaaS returns a single JWT string (signedPayload)
• Universal KYC returns a structured object containing identity fields and a signature

Both are valid for card creation but have different shapes — see the individual integration guides for details.

Webhooks

Reap uses webhooks to notify you of KYC status changes. All three KYC methods emit the same account_status_change event when an entity is approved, rejected, or when an individual requirement changes status.

You must register a webhook endpoint before processing users. See Webhook Setup to get started, and Webhook Notifications for the full payload reference.

Next Steps

Once you've chosen a method and familiarised yourself with the terminology above:

1. Set up your webhook endpoint → Webhook Setup
2. Follow your method's integration guide:
   • KYCaaS Integration Guide
   • SumSub KYC Sharing Guide
   • Universal KYC Guide