Geelab Docs

Glossary

Core Terms and Concepts

Core Concepts

captcha_id

Verification Public Key - A 32-character string, unique identifier for the captcha.

  • Publicly visible, used to distinguish verification modules on different pages
  • Obtained by creating in the Geelab console
  • It's recommended to deploy different verification IDs for each verification scenario

Example: a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

captcha_key

Verification Private Key - A 32-character string, uniquely corresponding to the captcha public key.

  • Used for data encryption in the verification service to ensure verification security
  • Generated after creating an ID in the Geelab console
  • Must be kept secure and not exposed in client-side code

Important: captcha_key is sensitive information and should only be used on the server side. Never expose it in frontend code.

lot_number

Verification Event Serial Number - Unique identifier for a single verification event.

  • Used to ensure the uniqueness of a single verification event and prevent replay attacks
  • Dynamically registered and obtained from the Geelab server through the deployed SDK
  • Each serial number is valid for approximately 10 minutes

Example: 4dc3cfc2cdff448cad8d13107198d473

sign_token

User Signature - Signature parameter used for secondary verification.

  • Generated using the HMAC-SHA256 algorithm
  • Calculated from lot_number and captcha_key
  • The secondary verification interface will only proceed with verification after confirming the signature is correct

Generation method:

sign_token = hmac.new(
    captcha_key.encode(),
    lot_number.encode(),
    hashlib.sha256
).hexdigest()

For complete signature generation documentation and multi-language examples, please refer to Server API - Signature Generation.

Verification Flow

Secondary Verification

The server-side verification process after a user passes the captcha on the frontend interface.

Process description:

  1. User completes verification on the frontend, generating verification parameters
  2. Frontend submits verification parameters to your backend
  3. Backend uploads these parameters to the Geelab secondary verification interface
  4. Geelab server confirms the validity of this user's verification
  5. Your backend decides whether to allow user operations based on the verification result

Secondary verification must be performed - Relying solely on frontend verification results is insecure; secondary verification must be performed on the server side.

Offline Mode (Disaster Recovery Mode)

Degradation handling mechanism when the verification service encounters an exception.

Frontend behavior:

  • When the service encounters an exception, the frontend will load a one-click pass local verification form
  • Ensures the frontend won't block normal page interaction flow

Backend handling:

  • Need to handle service exception situations (request timeout, request rejected, status code not 200)
  • It's recommended to allow requests during exceptions to ensure secondary verification doesn't block business flow

Offline mode ensures business continuity when the verification service encounters exceptions.

Verification Parameters

pass_token

Verification Pass Identifier - Token generated after user completes verification.

  • Generated by the Geelab server
  • Used to identify that the user has passed verification
  • Needs to be submitted during secondary verification

captcha_output

Verification Output Information - Encrypted data generated during the verification process.

  • Contains detailed information about the verification process
  • Used for server-side verification of user behavior authenticity
  • Needs to be submitted during secondary verification

gen_time

Verification Pass Timestamp - Time when the user completed verification.

  • Pure numeric string format
  • Used to prevent verification results from being replayed
  • Needs to be submitted during secondary verification

gen_time must be a pure numeric string and cannot contain other characters.

Verification Types

Slide Puzzle

Classic puzzle verification method where users need to drag a slider to complete the puzzle.

  • Security: Medium
  • User Experience: Good
  • Applicable Scenarios: General scenarios

Icon Click

Users need to click specified icons in order.

  • Security: High
  • User Experience: Lower
  • Applicable Scenarios: High-risk scenarios

One-Click Pass

Seamless verification where the system automatically determines risk level.

  • Security: Low
  • User Experience: Best
  • Applicable Scenarios: Low-risk scenarios

Nine-Grid Verification

Multi-touch verification method.

  • Security: High
  • User Experience: Lower
  • Applicable Scenarios: High-risk scenarios

Match-3

Fun verification experience.

  • Security: Medium
  • User Experience: Good
  • Applicable Scenarios: General scenarios

Gomoku

Innovative interactive verification method.

  • Security: Medium
  • User Experience: Good
  • Applicable Scenarios: General scenarios

Verification Modes

Intelligent Mode

System automatically selects verification type.

  • Intelligently assigns verification forms based on risk level
  • Allowed verification type combinations can be configured in the console
  • Achieves the best balance between security and user experience

Risk Control Integration Mode

Your server decides which verification type to display.

  • Specify verification type through API parameters
  • Can be dynamically adjusted according to business rules
  • Suitable for scenarios with custom risk control systems

Seamless Mode

No verification interface displayed, only behavioral analysis performed.

  • No verification interface displayed
  • Only performs behavioral analysis and returns risk score
  • Suitable for scenarios with extremely high user experience requirements

SDK

Software Development Kit - Code library for integrating verification services.

  • Web SDK: For web pages and H5 applications
  • iOS SDK: For iOS native applications
  • Android SDK: For Android native applications

API

Application Programming Interface - Interface for server-side secondary verification.

  • Verification Interface: Please use the corresponding domain based on the region you selected when registering your ID
    • Global: https://cap-global.geelabapi.com/validate
    • Europe: https://cap-eu.geelabapi.com/validate
    • North America: https://cap-na.geelabapi.com/validate
  • Supports GET/POST methods (POST recommended)
  • Returns JSON format data

Disaster Recovery

Disaster Recovery Mechanism - Degradation handling when the verification service encounters exceptions.

  • Client-side disaster recovery: Automatically handled by SDK
  • Server-side disaster recovery: Needs to be actively implemented by you
  • Goal: Ensure business continuity

Next Steps