Events
A funding round isn’t a field — it’s a moment. We split snapshots (what’s true now) from events (what happened, when). You trigger off events. You display snapshots.
Why split events from facts
If “raised $50m Series B” is a field, you have to diff two snapshots to know that something happened. If it’s an event with its own timestamp, the moment it’s detected your CRM workflow fires.
Events also handle the awkward cases that flat fields handle badly — a company can have three funding rounds. A flat last_funding_round_amount drops the other two. An event row keeps them all.
What an event looks like
{ "id": 8421, "entity_id": 1083, "entity_type": "company", "event_type": "funding_round", "event_subtype": "series_b", "happened_at": "2025-09-12", "observed_at": "2026-05-14T09:21:00Z", "payload": { "amount": 50000000, "currency": "USD", "round_name": "Series B", "lead_investor": "Sequoia Capital", "participating_investors": ["a16z", "Index Ventures"] }, "related_entity_ids": [1083, 2901, 3204], "corrects_event_id": null, "source_enrichment_id": 12455, "_meta": { "detector": "FundingRoundDetector", "evidence_url": "https://techcrunch.com/...", "confidence": 0.91 } }happened_at vs observed_at
When the event occurred, versus when we detected it. The Series B closed in September; we caught it in May. Both matter.
corrects_event_id
Events are immutable. If a detail was wrong — say, an acquisition date was misreported — a later event references the original and supersedes it. The audit trail survives.
related_entity_ids
A funding round connects the firm to its investors. An acquisition connects buyer and seller. The graph is implicit in this list.
source_enrichment_id
Which enrichment job detected this event. Lets you trace back to the evidence we used.
What we detect
Ten detectors run during every enrichment. Each one knows the phrasing, the evidence shape, and the payload schema for its event type. Detection is conservative — we’d rather miss a borderline case than emit a wrong event.
funding_round
Series A through pre-IPO. Carries amount, currency, round name, lead investor.
ipo
Initial public offering. Carries exchange, ticker, listing date.
acquisition
Acquired by another company. Carries acquirer ID, announced date, close date.
divestiture
Sold a business unit or subsidiary. Carries the divested entity reference.
restructuring
Layoffs, reorganisation, division splits. Carries scale and rationale where available.
leadership_change
C-suite or board appointment, resignation, succession. Carries role, person, effective date.
auditor_change
Switched audit firms. Carries outgoing and incoming firm, effective date.
regulatory_crossing
Crossed a regulatory threshold — AIM, FCA-regulated, public-interest entity.
job_change
For person enrichments — moved roles, moved firms.
senior_role_posting
Open vacancy at director level or above. Carries role title, function, location.
Detectors are evidence-bounded
leadership_change, auditor_change, regulatory_crossing, job_change, senior_role_posting) also need prior-state evidence — a previous snapshot to compare against. They start firing once an entity has been enriched twice.Pulling events out
# All events from one enrichment curl https://abm.dev/v1/enrichments/{id}/events # All events for an entity over time curl https://abm.dev/v1/entities/{entity_id}/events # Filtered to a specific type curl 'https://abm.dev/v1/entities/{entity_id}/events?type=funding_round'Trigger patterns we’ve seen work
Funding round + ICP fit → Slack ping to the AE
When a funding_roundevent lands on an entity with ICP match > 0.75, your workflow nudges the rep.
Senior role posting → outreach sequence with role-aware copy
senior_role_postingin your buyer’s function tells you the seat is being filled. You time outreach to the moment the new hire lands.
Auditor change → re-qualify and reach out
For an audit firm, an auditor_changeat a target account is the cleanest possible trigger. It happens once a decade. Don’t miss it.