Integration and APIs

Early Warning is built to sit inside an existing environment rather than beside it. Data arrives on a schedule from the sources you register, metrics and alerts leave over a documented API, and the whole product runs on infrastructure you control.

Nothing on the integration path is bespoke. The same API the interface uses is available to your own scripts and services, so an operation can automate against the platform without waiting for a connector to be written.

Ingestion is managed as configuration rather than code. Sources are registered with their schedule and their endpoint, and every run is logged, so a gap in the data becomes visible before it turns into a gap in the alerting.

• A source registry with per-source schedules and on-demand triggering.
• Run history and logs per source, so failures are diagnosable rather than silent.
• Import of external geospatial layers such as FeatureServer services and GeoJSON files.
• Metrics defined over what is already there, with no second copy of the data.

Reads and writes go through the same versioned API surface, which means a dashboard, a script and a rule all see the same numbers. There is no reporting copy to reconcile, and no export that quietly ages while the source moves on.

• REST endpoints for current values, series, metrics, alerts and their state.
• Token-authenticated access, so machine integrations are identified and revocable.
• CSV and GeoJSON export of the data behind a view or a query.
• Generated PDF reports for the briefings that still travel as documents.

A typical integration is small. A script reads the current value of a metric on a schedule and publishes it into another system, or an internal tool writes an event in through the API and lets the rules decide whether it matters.

The surface is deliberately not read-only. Records such as board cards, events and custom data points can be created and updated through the same authenticated endpoints, with the same role checks the interface applies.

• Read a metric or a series on a schedule and publish it elsewhere.
• Write events in from an internal system, so rules can watch them too.
• Pull alerts into an operations channel without a second source of truth.

Access is scoped by role and the API is closed by default: endpoints require credentials rather than trusting the network boundary. Administrative actions and security-relevant changes are written to an audit log.

That matters most where the alerting data is sensitive. Who can read a series, who can change a rule, and who acted on an alert are all answerable questions, and the answers do not depend on anyone remembering.

The product runs inside your own environment — application, database and API together — with inference kept local rather than routed to an external model. Operational data does not have to leave the network to be scored, alerted on or reported.

Deployment is a small stack you can host yourself, which keeps the data path short and the operational responsibility clear. There is no third-party hop between your sources and the alerts you receive.

Your infrastructure, your database, your data path — no third-party hop in the middle.

An integration that worked on the day it was written is not finished. Sources change, credentials expire, and a run that stops delivering is only harmless if somebody notices, which is why each source keeps its own run history and failure log.

Credentials are issued per integration and can be revoked individually, so removing a consumer is one action rather than a hunt. The API itself is versioned, which makes an upgrade a reviewed change instead of a surprise.

• Check the run log of a source the same way you check its dashboard.
• Issue a separate credential for every integration and revoke it when the consumer retires.
• Treat an API version change as a scheduled, tested change.

The quickest start is to register one source you already have an endpoint for, confirm its run log, and build a single rule on top of it. From there an export, an API consumer and a response board all follow the same pattern.

Bring the endpoint and a credential for it, and the first integration is usually finished and verified in a single session. Everything after that is repetition of a pattern your team already understands.