Skip to main content
POST
Create Onboarding Consent

Overview

Creates a new consent set during user onboarding using the onboardingId from the registration flow. This endpoint is typically called after personal details submission and before address submission during the registration flow.
Use the onboardingId returned from email verification (POST /v1/auth/register/email/verify) - do NOT generate a new ID. This links the consent to the user’s registration session.

Use Cases

Mobile App Registration

Collect consent during mobile app onboarding flows

Web Registration

Capture consent on web registration forms

KYC Processes

Record consent during identity verification

Pre-Registration Consent

Collect consent before user account creation

Endpoint

Headers

Security: The x-secret-key should only be used in server-side code. Never expose it in client-side applications.

Request Body

Parameters

Metadata Fields (Optional)

Additional custom fields can be included in metadata. All fields must be JSON-serializable.

Examples

US Policy (All 5 Consents)

Global Policy (4 Consents, No eSignAct)

Response

201 Created

Success Response:
Response Fields:
Store the consentSetId: You’ll need this to link the user after account creation completes.

400 Bad Request - Missing Required Consents

Cause: Not all required consents for the policy type are present. Required Consents:
  • US Policy: All 5 types (including eSignAct for E-Sign Act compliance)
  • Global Policy: 4 types (excludes eSignAct)
Cause: Using an unsupported consent type.

409 Conflict - Duplicate Onboarding ID

Cause: The onboardingId has already been used. Solution: Generate a new unique onboardingId and retry.

498 Invalid Client Key

Cause: Invalid or expired API credentials.

499 Missing Client Key

Cause: Missing x-client-key header.

Validation Rules

  • Must be the onboardingId from registration email verification
  • Do NOT generate a new ID - use the ID from POST /v1/auth/register/email/verify
  • Format: UUID string (e.g., 100a99cf-f4d3-4fa1-9be9-2e9828b20ebb)
US Policy requires all 5 consent types (E-Sign Act compliance):
  • eSignAct (required for E-Sign Act compliance)
  • termsAndPrivacy
  • marketingNotifications
  • smsNotifications
  • emailNotifications
Global Policy requires 4 consent types (excludes eSignAct):
  • termsAndPrivacy
  • marketingNotifications
  • smsNotifications
  • emailNotifications
Include these fields for comprehensive audit trails:
All values must be JSON-serializable (no functions, circular references, or undefined).

Code Examples

TypeScript

Python

cURL

Next Steps

After creating the consent set:
  1. Store the consentSetId: You’ll need it to link the user later
  2. Complete user registration: Finalize account creation in your system
  3. Link user to consent: Call Link User to Consent Set

Link User to Consent

Associate userId with consent set after registration

Get User Consent Status

Check user’s consent status

Get Consent Audit Trail

Retrieve complete consent change history

Implementation Guide

Full integration guide with examples