Data lifecycle
How an event matures before Datahyena serves it, and why you never receive a half-formed record.
Between something happening in the world and it reaching you, Datahyena holds each event until it is complete. This page explains that lifecycle so you know exactly what you are storing.
From event to record
Every signal moves through the same stages before it is served:
- Discovered. An event is first seen across one or more public reports.
- Resolved and enriched. The companies, investors, and people involved are matched to canonical entities and filled in. See entity resolution.
- Matured. The event is held until it has settled: it has stopped attracting new reports, its entities have finished resolving, and it clears a confidence bar. Corroboration from multiple sources raises confidence.
- Served. Only now does the event appear in the API and fire over webhooks.
The point of stage 3 is that you never receive a half-formed stub. By the time an event reaches you, the amount, round, entities, and sources have settled.
Because events mature before delivery, you do not need to build reconciliation logic for partially-populated records. What you receive is the settled version.
Fire-once webhooks, no .updated
Webhooks deliver each event once, when it matures. There is no funding.updated, acquisition.updated, or exec_move.updated event, because the record is already settled when it fires. Every delivery carries a deterministic envelope id, so if a delivery is retried you can dedupe on that id and process each event exactly once. See Security for retry and signature details.
An event that never fully settles is still delivered after a bounded wait, with everything known at that point, so nothing is silently dropped.
The pull API always returns current state
A GET against a list or single-record endpoint returns the event as it stands at query time. In the rare case that a late correction lands after an event was first served, re-fetching it, by re-querying the list or fetching it by id, returns the freshest version. If you need the absolute latest for a specific record you have stored, fetch it by its id.
What to rely on
- Store by the stable id. Event ids and
companyIdare stable join keys, safe to persist. - Trust the delivered record. It is the matured version, not a draft.
- Re-fetch by id when you need to confirm the current state of something you stored earlier.