Integration data reference
Smart Helmet Integration Data Reference
Review the operational records and field groups that can be mapped from selected G808 and G901 workflows into an existing customer system. Use this reference to define identifiers, alarms, location, media and acceptance requirements before development begins.
Last reviewed: August 12, 2026
Direct answer
What information can an enterprise Connector map?
The reviewed service interface covers organization and user records, device identity and operating state, location tracks, configured alarms, recorded media, selected intercom records, live-media session information and selected device messages.
Availability depends on the device model, application configuration, user permissions and deployment environment. The exact record set is confirmed in the project scope and then validated with representative devices.
Business records
Organizations, users, devices, assignments and selected operating-state fields can support customer asset and workforce records.
Operational events
Location tracks, configured alarms and selected media metadata can support monitoring, incident and audit workflows.
Field population
Not every documented field is populated by every model, configuration or workflow. Required fields are frozen before development.
Timing and scale
Update frequency, retention, request limits, media access and recovery behavior require representative acceptance testing.
Record families
Plan around distinct records—not one generic data feed
Each record family has its own identifiers, filters, timing and customer responsibility. Keeping them separate produces clearer requirements and more reliable integrations.
Organizations
Hierarchy, codes, names and selected site/contact attributes.
Users
Worker references, roles, status and organization relationships.
Devices
Device identity, model, assignment, version and online state.
Location
Timestamped coordinates, altitude, speed and bearing.
Alarms
Configured alarm type, time, device, user, site and location context.
Recorded media
Image, video, intercom and audio records with controlled references.
Live media
Authorized session information for a qualified RTSP workflow.
Device messages
Selected text and media instructions sent to approved devices.
Organization and user fields
Connect source identities to the customer’s own structure
A reliable Connector needs an explicit mapping between service-layer records and the customer’s tenants, sites, teams, workers and roles.
| Record | Customer-facing fields | Format | Typical use | Confirm in project |
|---|---|---|---|---|
| Organization | Record ID, organization code, organization name, parent organization reference | identifier / text | Map source departments or sites to customer tenants, locations and teams | Hierarchy ownership, stable mapping key and update rules |
| Organization details | Contact name, contact phone, address and optional coordinates | text / coordinates | Support selected site administration records | Need, consent, minimization and coordinate reference |
| User | User record ID, name, worker/job number, role/job and account identifier | identifier / text | Associate devices and operational records with an authorized worker | Customer worker key, personal-data policy and lifecycle |
| User access | Organization relationship, account status, communication priority and user-role flags | identifier / enum | Support selected role and communication workflows | Enumeration, permissions and whether each field is populated |
Identity rule
Keep source record references and customer record references as separate fields. Do not replace one with the other or assume a person, device or organization will keep the same assignment forever.
Device fields
Maintain an authorized device registry
Device records can support fleet inventory, assignment and operating-state views. They do not represent unrestricted access to every Android or sensor property.
| Field group | Customer-facing fields | Format | Typical use | Confirm in project |
|---|---|---|---|---|
| Identity | Device record ID, device ID, device code and display name | identifier / text | Map a source device to the customer’s asset record | Stable key, replacement and re-enrolment behavior |
| Hardware and connectivity | Model, IMEI, SIM identifier and application version | text | Fleet support, configuration and version governance | Permission, privacy need and which identifiers may be stored |
| Assignment | Organization reference, organization code, assigned user reference, assigned user name and worker number | identifier / text | Relate a device to a site, team or worker | Assignment timing and reassignment lifecycle |
| Last reported state | Online status, last reported coordinates and address | enum / coordinates | Fleet availability and selected monitoring views | Freshness, update interval, location source and coordinate system |
| Communication state | Selected intercom-group, intercom-call, video-call, monitoring, recording and broadcast flags | enum / boolean-like | Support approved communication-state displays | Exact enumeration, freshness, permissions and model support |
Location fields
Normalize coordinates, time and device identity together
Location records are useful only when their coordinate reference, timestamp, unit and device relationship are understood by the destination system.
| Field | Meaning | Format or unit | Typical use | Confirm in project |
|---|---|---|---|---|
| Device reference | Identifies the source device that produced the track point | identifier | Associate the point with a customer asset or worker assignment | Identity mapping and reassignment timing |
| Longitude and latitude | Track-point coordinates | decimal coordinates | Map display, route history and selected location rules | The reviewed document identifies GCJ-02; overseas behavior and any conversion must be confirmed |
| Capture time | Date-time plus a timestamp field | date-time / integer | Ordering, playback and synchronization | Time zone, timestamp unit, clock synchronization and late records |
| Altitude | Reported altitude | metres | Selected operational context | Availability and accuracy for the selected device/configuration |
| Speed and bearing | Reported movement speed and direction | m/s / angle | Selected movement and route workflows | Update rate, accuracy, bearing reference and stationary behavior |
Alarm fields
Map configured alarms into customer incident workflows
The reviewed record family includes contextual fields for selected configured alarms. Actual alarm support depends on the device, enabled sensors, application configuration and project scope.
| Field group | Customer-facing fields | Typical use | Confirm in project |
|---|---|---|---|
| Event identity | Source record reference, alarm type and alarm time | Create an idempotent customer incident record | Stable source key, enumeration and time-zone handling |
| Device and worker | Device reference, device name and assigned user name | Relate an incident to the correct asset and worker | Assignment timing and privacy rules |
| Organization | Organization name and related source references | Route an incident to the correct site or team | Customer hierarchy mapping |
| Location | Longitude and latitude at the alarm record | Display incident location and support selected response workflows | Coordinate reference, freshness and missing-location handling |
| Rule context | Rule name, geofence name and correlation key where available | Explain why an alarm occurred and associate selected media records | Population, alarm-to-media completeness and correlation behavior |
Alarm categories identified in the reviewed material
- SOS
- Helmet-off
- Geofence entry or exit
- Impact
- Proximity-to-electricity
- Silence/inactivity and height/climbing
Do not assume
- Every category is enabled on every device.
- Every alarm contains complete location or media.
- The customer system receives an automatic webhook.
- A successful record query proves the end-to-end response workflow.
- Alarm timing is identical across all networks and environments.
Recorded media fields
Treat media metadata and file access as separate responsibilities
A media record can identify a file and its context. The customer Connector still needs to handle authorization, reference lifetime, retention, download behavior and any approved destination storage.
| Field | Meaning | Format or unit | Typical use | Confirm in project |
|---|---|---|---|---|
| Media record ID | Source reference for the media record | identifier | Deduplication and traceability | Stability and retention |
| Media type | Image, video, intercom recording or audio | enumeration | Route the record to the correct customer workflow | Supported types per device and scenario |
| Authorized media reference | Controlled path or URL returned for the record | text / URL | Retrieve or play approved media | Lifetime, authentication, download rights and external reachability |
| File metadata | File name, start time, byte size and audio duration where applicable | text / date-time / bytes / seconds | Display, storage planning and validation | Time zone, format, maximum size and completeness |
| Operational context | Device user name, worker number, organization code and device code | identifier / text | Relate media to an approved worker, site and device | Mapping, privacy and authorization |
Live media and messages
Separate session workflows from ordinary record retrieval
Live media is session-oriented. The reviewed interface includes functions for requesting and closing an authorized RTSP session and obtaining related server information. This does not by itself define browser playback, return audio, latency or production concurrency.
Live media
A qualified workflow can request session information for an approved device and pass it to an authorized player or video system.
Playback behavior
Codec, authentication, network reachability, latency, timeout, reconnection and concurrent sessions require acceptance testing.
Device messages
Selected text and media instructions can be targeted to approved device references when included in the project scope.
Authorization and audit
The destination system must control who may start a session or send a message and retain an appropriate audit trail.
Retrieval model
Design for authenticated, paged service access
The customer Connector should manage service credentials and token lifecycle on the server, apply approved filters, read complete result pages and advance a durable checkpoint only after successful processing.
- 1
Authenticate on the server
Keep service credentials and tokens out of browser code, public downloads, screenshots and client-side applications.
- 2
Apply approved filters
Limit requests to the required organizations, devices, users, record types and time range.
- 3
Read every page
Track current page, page size, total records and total pages before completing a retrieval cycle.
- 4
Map and normalize
Preserve source references while mapping customer IDs, time zones, enumerations, units and coordinates.
- 5
Prevent duplicates
Use source record references, object type and controlled overlap so retries do not multiply customer incidents.
- 6
Monitor and recover
Record successful checkpoints, retry transient failures and surface mapping or authorization errors for review.
Acceptance checklist
Confirm these items before production
The data model is only one part of the integration. Production readiness depends on measured behavior, ownership and recovery.
Data and mapping
- Required record families and fields
- Stable source and customer identifiers
- Enumerations, units and missing values
- Time zone and timestamp normalization
- Coordinate reference and overseas behavior
- User, device and organization lifecycle
Operation and security
- Roles, permissions and credential storage
- Paging, request limits and retention
- Polling interval and acceptable delay
- Retry, overlap and duplicate prevention
- Media authorization and lifecycle
- Monitoring, incident response and change control
Customer-owned APK projects
A customer-owned APK follows a different path. Android APIs, hardware modules, local device logic and direct backend communication require model-specific device documentation and a separate field catalogue. They are not implied by this service-layer reference.
Data reference FAQ
Common integration-data questions
Does this page list every available service field?
It lists the customer-relevant field groups found in the reviewed material. Exact private field names, endpoint paths, permissions and project examples are shared during a qualified technical process and frozen in the project mapping catalogue.
Are all fields available for both G808 and G901?
Not automatically. Availability depends on the model, enabled application, sensors, permissions and deployment. Required fields are confirmed for the selected configuration and validated with representative devices.
Can we receive alarm records in our own system?
Selected configured alarm records can be mapped through the Enterprise Integration route. The reviewed standard method is authenticated retrieval. Event push or webhook delivery is separate engineering unless specifically confirmed.
Can recorded video and live video use the same integration?
No. Recorded media is discovered through records and controlled file references. Live video requires a session, an authorized player or media system, and separate tests for codec, latency, authentication, reconnection and concurrency.
Which coordinate system is used?
The reviewed location-track and alarm material identifies GCJ-02 coordinates. Overseas coordinate behavior and any conversion to the customer’s required map reference must be confirmed in the deployment and tested.
Does this route provide direct access to Android APIs or raw sensors?
No. This reference describes service-layer records for Enterprise Integration. Direct Android APIs, customer device logic and selected hardware-module interfaces belong to a customer-owned APK project and require model-specific documentation.
Related resources
Turn the field reference into a testable integration
Architecture & Connector Guide
Review the service boundary, mapping lifecycle, ownership and recovery pattern.
Enterprise Integration
Check whether the route fits the customer’s system, team and delivery expectations.
Data, Alarm & Media Guide
Compare operational data layers and capability boundaries across routes.
Pilot Test Plan
Convert required records, media and timing into measurable acceptance criteria.
RFQ Checklist
Collect the technical, commercial, compliance and rollout inputs needed for quotation.
Resource Center
Browse HelmetSight buyer, deployment and technical planning guides.
Define the records your system actually needs
Share the destination system, device models, required users and sites, alarm categories, media workflows, expected scale and acceptance targets. HelmetSight can then help define the appropriate integration review and pilot scope.