Deployment Guide
Entry points and shared integration flow for Web, Android, and iOS
Device fingerprint integration has two parts: the client collects and reports signals, while the server performs the final query and business decisioning. Start with the shortest path first, then expand your policies step by step.
Platform Selection
Web Integration
For H5, desktop web, and embedded WebView scenarios
Android Integration
For native Android client integration
iOS Integration
For native iOS client integration
Server Query
See fp_query request structure, response fields, and error codes
Shared Integration Flow
Create an App
Create an app in the console, obtain appId, and plan isolation by region, business line, or environment when needed.
If different regions or business lines require separate risk strategies, split apps early to avoid expensive migration later.
Integrate the Client SDK
Initialize the SDK on Web, Android, or iOS, and retrieve respondedGeeToken or geeToken during key business requests.
Submit Business Context
Send the token together with request ID, user ID, order ID, scenario markers, and other business context to your server for downstream decisioning.
Query on the Server
Use the device fingerprint service flow on the server to call fp_query and obtain final fields such as fp, risk_code, and risk_label.
Do not store private_key on the client, and do not treat the original client token as direct input to fp_query.
Validate and Go Live
Verify both online and fallback token paths in a test environment before wiring risk results into production policies.
Integration Recommendations
- Finish the shortest path on one platform before expanding to others
- Plan apps with region, platform, and scenario boundaries in mind
- Map
risk_codeandrisk_labelexplicitly to business actions - Monitor query failures, fallback paths, and high-risk device hits
Next Steps
- Read Quick Start for the shortest integration path
- Check FAQ for common integration issues