Core objects and data relationships
Geelab uses a hierarchical structure to manage member permissions, data areas, business applications and technology access. Understanding the relationships between these objects helps to correctly plan applications, keys, and data query scopes.
object relationship diagram
Core object description
organization
Organizations are the top-level container for members, subscriptions, product access, and business assets. The organization owner is responsible for organization management, and invited members access the dashboard according to their assigned product access.
Region
Region is the boundary for data storage, processing, and key isolation. Applications must select a Region when created, and the choice cannot be changed later. It determines:
- Where application data is stored and processed.
- The scope of the Region server key.
- The applications that a Webhook can be bound to.
- The query boundary for event and device data.
Application
An application represents an independent business project, such as a main mall website, a payment product, or mobile banking. Applications are business containers for data, quotas, and integrations.
integrations
- Platform type.
- Public API Key.
- Source or application signature verification configuration.
- Request rate-limit configuration.
- Enable or disable status.
For example, a "mall" application can create three integrations: "Web settlement page", "iOS client" and "Android client".
event
An event is a record formed in Geelab for one device identification request. Each event is uniquely identified by request_id and associated with its organization, Region, application, and integration.
device
A device is a device view aggregated by device_id within a specific application's data scope. Device details summarize the following during the current data-retention period:
- Time of first appearance.
- Last access time.
- Number of events.
- Risk signals that have been hit.
- Recent and historical device environments.
- Event log.
Devices represent the aggregation results of device dimensions and do not represent real natural person profiles.
risk signal
A risk signal has a Signal Code, description, risk classification, risk level, and supporting platform. The signal names and descriptions in the console should be based on the Unified Risk Signal Dictionary.
Permissions and data isolation scope
| Object/Ability | main scope | Main permission requirements | Quarantine rules |
|---|---|---|---|
| Organization settings | Organization | Organization owner; members receive product access within each organization | Members, assets, and subscriptions are isolated between organizations |
| Member management | organization | organization owner | Member permissions only take effect for the current organization |
| Region | Data area within the organization | Device Fingerprint read-only or read-write access | Applications, keys, and data in different Regions are isolated |
| Application | Organization × Region | Read-only or read-write access to view; read-write access to configure | An application can belong to only one Region |
| Integration | Application | Read-only or read-write access to view; read-write access to configure | A Public API Key applies only to its integration |
| Event | App × Region | Device Fingerprint read-only or read-write access | Query results cannot be mixed across applications or Regions |
| Device | App × Region | Device Fingerprint read-only or read-write access | Device aggregation is scoped to the current application and Region |
| Risk signal statistics | Applications in the current Region, or all accessible applications in that Region | Device Fingerprint read-only or read-write access | "All Applications" aggregates only the current Region |
| Server key | Region | It is recommended to limit access to key management | Application sharing under the same Region cannot be used in other Regions |
| Webhook | Region × application collection | It is recommended to limit configuration management rights to | Only applications under the selected Region can be bound |
Member access is granted per product. Device Fingerprint supports three states: read-write, read-only, and no access. High-risk operations such as server-key rotation, member management, application deletion, and Webhook changes remain subject to organization-role restrictions and confirmation requirements.