Granular and aggregated access
Query individual reports or pull pre-aggregated summaries, depending on whether you are driving an interface or feeding a model.
API · Partners & integrators
Public API
The same intelligence layer, open to partners.
Everything our own products run on is available programmatically. The API exists so partners, researchers, and integrators can build against the network without rebuilding the ingestion, verification, and normalization work underneath it.
01 — In the product
What working with it looks like.
There is no interface to show you — the API is the part other systems build on. So here is the shape of an integration instead.
- 01Authenticate
Every request carries a key in its header. Keys are issued per integration, so access stays attributable and can be revoked without disturbing anyone else building on the network.
- 02Query
Ask for individual reports or pre-aggregated summaries, narrowed the same way our own products narrow them — by geography, hazard category, and time window.
- 03Receive normalized data
Responses arrive in one consistent shape no matter which upstream source a record originated from. The reconciliation work between incompatible feeds has already happened on our side.
- 04Build against stable contracts
Endpoints, parameters, and response shapes are documented and versioned, with a published ceiling of 100 requests per hour per IP — stated up front so you can design against it rather than discover it in production.
02 — What it does
Built around four things it has to get right.
Key-based authentication
Access is authenticated per key via request header, so usage is attributable and revocable per integration rather than per organization.
Published rate limits
A documented ceiling of 100 requests per hour per IP, stated up front so integrators can design against it instead of discovering it in production.
Normalized output
Responses arrive in the same internal representation our products consume — the multi-source normalization is done before it reaches you.
03 — How it works
The path a signal takes.
Enough of the architecture to judge whether we know what we are doing — not enough to hand someone a blueprint.
Serverless edge
Endpoints run as serverless functions, scaling with demand and keeping latency low without a fleet to operate.
Scheduled ingestion
Environmental hazard data is processed by dedicated ETL workers on a schedule, so upstream sources are polled on our cadence rather than on a caller’s request path.
Authentication and throttling
Keys are validated and usage metered before a request reaches data, keeping abuse away from the systems the live products depend on.
Stable contracts
Endpoints, parameters, and response shapes are documented and versioned, because an integration that breaks silently is worse than one that was never built.
04 — The tech
What it is built on.
API
Node.jsExpressServerless functions
ETL
Python processorsScheduled CI workers
Data
FirebaseNormalized hazard store
Infrastructure
Vercel
Data sources
Public API draws on authoritative external feeds alongside our own network, so community reporting is corroborated rather than taken on faith.