CPR Client Integration Step-by-Step Guide
- Understand CPR Functions before starting with the integration
- Review different scenarios in CPR Auth (Miro) — first step is to understand the client's use-case and qualify the type of integration
Client Side Tasks
Common to all scenarios:
- Client calls the Generate Auth API in their backend with appropriate parameters to get the authToken
- The authToken is specific to the user — the same token cannot be used for multiple users
- Client needs to share static IPs from where the Generate Auth API will be called. These IPs need to be whitelisted at HV end
Integration Scenarios
| Scenario | authenticateOnResume | mobileNumber/Email |
|---|---|---|
| Scenario 1: Client doesn't want HV Auth on any platform (they have their own auth) | no | not required |
| Scenario 2: Client wants HV Auth on all platforms, has access to user's phone/email | yes | required |
| Scenario 3: Client wants HV Auth on all platforms, does NOT have access to user's phone/email | yes | not required |
| Scenario 4: Client wants HV Auth on some platforms but not others — (a) platforms with HV Auth, (b) platforms with client's own auth | (a) yes, (b) no | (a) required, (b) required |
Scenarios Not Supported
Client wants HyperVerge to handle auth on some platforms but not others, and they don't have access to user's phone/email.
Special Scenarios
Output API called in user's journey (Extension to Scenario 3):
When there are two workflows — Workflow 1 done by agent, Workflow 2 done by user — and the Outputs API is called in Workflow 2 to get user details from Workflow 1:
- Risk: An attacker could complete mobile OTP verification with their own number and access PII from the Outputs API
- Solution: Outputs API should be called by the verify-otp Thomas API, which returns success only if mobile OTP verification succeeds AND the mobile number matches
- Preferred
triggerModuleId: The module that comes after the main OTP module
HV Side Tasks
Get Client IP whitelisted
- Ensure IPs shared by the client are static
- Raise a request in
#platform-requests-channelto whitelist these IPs- Star whitelisting is supported for staging AppIds
Enable CPR + CPR Auth in workflow
See CPR Auth section in CPR Functions for configuration details including:
- Auth Config (serverSideResume object)
- Mini Auth Flow setup
- Sample configs
Configure Prevent Parallel Sessions (if required)
See Prevent Parallel Sessions for config details.
Add workflowVersion in properties (if required)
See Workflow Versioning.
Add ignoredStateRefreshInputKeys (if required)
Convert Local Paths to URLs
See Handling LocalPaths and Base64 strings for why this is required and how to configure it in the builder.
Configure expiresAfter (if required)
See expiresAfter.
Configure exitOnEndStates (if required)
See exitOnEndStates.
Configure resumeFrom (if required)
See resumeFrom.
Configure skipCPRPut (if required)
See Skip CPR Put.
Enable Dashboard State Reset for the client (if required)
Enable webcore (mandatory for Mobile SDK with CPR Auth)
Upgrade Link-KYC Version (if link-kyc is used)
Minimum WebSDK version required for CPR Auth: 8.12.0
To upgrade, raise a request in #platform-sdks-requests.
Test Cases
After integration, verify the following:
- User dropped off on one platform (e.g., Web SDK) and can resume on the same platform
- User dropped off on one platform and can resume on a different platform (e.g., Mobile SDK → Web)
- If
expiresAfteris configured, user restarts from that module after expiry - If
resumeFromis configured, user resumes from the specified module when conditions are met - If
exitOnEndStatesis configured, the user cannot restart the journey on configured end states - If CPR Auth is enabled: user is asked to authenticate on resume, and can retry verification if it fails
Sanity Checklist
- Client Side Tasks (above) are completed
- HV Side Tasks (above) are completed
- E2E Tests (above) are completed
Related: