Raw packet receiver
HTTP endpoints capture JSON, text, hex, form, and binary bodies. Optional TCP/UDP listeners preserve Teltonika-style packets.
Internal GCCAP operating surface
This page is retained behind the public client website.
GCCAP does not delete operating records, trial packs, hardware activation surfaces or evidence automation layers. They are preserved for authorised client portal, command-centre and internal operating use while the public website stays clean for airline first impressions.
Open portal accessInternal GCCAP surface
Ready to receive unknown sensor/server output without losing evidence.
GCCAP creates the intake foundation for Teltonika FMC150, Bluetooth cold-chain sensors, gateway feeds, server webhooks, and future telemetry sources. It captures raw packets first, inspects unknown fields, maps them into GCCAP standard events, and keeps the original source evidence intact.
StatusInternal / restricted surface. Not part of the public client walkthrough.
GCCAP
Sensor
Gateway
Evidence
Watchdog
Journey intelligenceRepresentative demo
Build statusRaw capture + registry + mapping
Data positionPreserve first, decode second
Production gateNeeds real server payload sample
Operational layer
What Build 2 adds
This layer is designed for the exact uncertainty GCCAP has now: the device/server payload format is not confirmed yet.
Raw packet vault
Every intake packet is stored with timestamp, source, content type, size, SHA-256 hash, preview, and a blob reference.
Payload inspector
The internal intake lab shows packet history, source metadata, field extraction status, normalised events, and data quality warnings.
Field mapper
Default mappings search for temperature, timestamp, location, gateway, sensor, cart, battery, signal, and journey hints. Mappings can be updated when real payloads arrive.
Registry foundation
Devices, sensors, carts, and assignments can be created before the full client portal build.
Evidence-first architecture
Unknown data is not discarded. Malformed or unmapped data is preserved for later replay and decoder improvement.
Data path
Intake path
Build 2 positions GCCAP to accept the first real sensor/server output quickly, then harden the decoder once the actual payload is confirmed.
01Sensor captures cart temperature behaviour
02Gateway collects sensor records
03Raw payload is received and preserved
04Payload is mapped to sensor, cart, gateway, site and client
05Temperature event is normalised into the GCCAP event model
06Event is assigned to the correct cart journey stage
07Rules engine flags warning or review conditions
08Recovery and duration are calculated
09Data completeness and hardware health are assessed
10Evidence report is prepared for private client review
11Approved outputs can support client action and future benchmark methodology
Decision clarity
Build 2 readiness checklist
The platform is now ready for controlled technical testing, not full commercial production.
HTTP intakePOST /api/ingest/raw, /api/ingest/json, /api/ingest/teltonika, or /api/telemetry.
TCP listenerOptional Teltonika TCP listener can capture IMEI handshakes and AVL packets when enabled.
UDP listenerOptional UDP receiver captures raw datagrams for unknown/forwarded feeds.
StorageRaw blobs plus metadata NDJSON and normalised event NDJSON are written locally for pilot/dev use.
SecurityProduction requires GCCAP_INGEST_TOKEN and GCCAP_ADMIN_TOKEN before external exposure.
Next build dependencyBuild 3 will convert this foundation into real telemetry storage and journey-ready event handling.
Strongest next move
Next technical action
When the Teltonika/server output arrives, send one or more raw sample payloads through Build 2. GCCAP can inspect the fields, update mappings, and lock the decoder without losing source evidence.
Request a controlled pilot