The event arrives. The record holds.
The inbound-event surface of the estate: every event that crosses in is received once, kept, and answerable — behind a front door that serves machine callers cold today, with every gate to the rest stated in the open.
A builder whose product is driven by events from systems they don't control — the payment settled, the PR merged, the call ended, the row changed — is offered everything except the arrival itself. The webhook incumbents sell outbound delivery (sending your webhooks for you) or inbound relay (getting them to your handler) — and the relays do keep a delivery log: search, filters, attempt inspection, replay, on the relay's retention clock, all oriented at the hand-off. What nobody sells the builder is the arrival as a record of their own — kept on their terms, answerable long after any retention window closes. So every integration either carries the practice in-house — receipt, signature verification, retry tolerance, dedupe, storage, replay — or rents it a retention window at a time. And when a provider says "we sent it," the builder has a log line or nothing.
The failure is quiet and constant: "the event fired three days ago and I cannot prove whether we received it" is not an outage, so it never gets fixed — it gets re-lived. In a machine economy the event is how anything learns that anything happened. If arrivals are not first-class — received once, kept durably, answerable later — everything downstream of them is built on hearsay.
This record ships in a batch with its two nearest siblings, and the boundary between the three is drawn by rule, not by roadmap:
Two more coordinates complete the messaging picture and are stated at their filed reality: events.do, the internal bus (registry P0, implemented) — a name with no serving zone of its own anywhere today, worn as an amber on the seams slide rather than rounded up — and queue.do, buffered work distribution (registry planned; no serving zone). One event, four grains: webhooks receive, triggers decide, actions do, the bus carries.
GET https://webhooks.do — cold, no login, no signup — answers with a
typed descriptor of exactly what this door is (abridged; the
caller-context block is omitted):
{
"api": {
"name": "webhooks.do",
"description": "Event streaming, ingestion, and analytics for the .do platform",
"version": "0.2.0",
"from": "https://platform.do"
},
"links": { "mcp": "https://webhooks.do/mcp", "ingest": "https://webhooks.do/e" },
"discover": {
"Ingest Events": "POST https://webhooks.do/e",
"Webhooks": "https://webhooks.do/webhooks",
"All Events": "https://webhooks.do/events",
"Commits": "…", "Errors": "…", "Traces": "…", "Analytics": "…",
"AI Events": "…", "CDC Events": "…", "Tail Events": "…"
}
}
The descriptor is the offer: one ingest endpoint, named surfaces for
webhooks, events, commits, errors, traces, and analytics, and a machine
door at /mcp. Note "from": "https://platform.do" — the door files
its own operator in its own bytes, the same relationship this record
files in its frontmatter.
Concreteness over adjectives: each door below was checked cold on 2026-07-31 and carries its own state and its own evidence URL — never one URL evidencing several domains. Serving is a liveness fact, not a tenancy claim: nothing here asserts external tenancy, metered billing in production, or an event-volume roll. Those publish behind their own gates.
webhooks.do serves. The apex answers a cold machine caller with the
typed JSON descriptor above — no login, no signup — self-describing as
"Event streaming, ingestion, and analytics for the .do platform",
version 0.2.0.
The machine door serves: GET https://webhooks.do/mcp returns an MCP
capability listing cold — three tools: events_search,
events_count, events_sql.
The authenticated surfaces answer as typed doors, not missing routes:
GET https://webhooks.do/webhooks returns the same structured envelope
with an authentication challenge, and its links route login to the
estate's identity door — https://id.org.ai/login.
The identity door those envelopes route to serves in its own right:
GET https://id.org.ai/login answers 200 cold with the estate's
sign-in page — the login path the authenticated surfaces post is a
live door, checked at its own URL, not inferred from the envelope
that names it.
triggers.do serves — the batch sibling holding the condition grain is
live, titled "Manage Event-Driven Workflows at Scale" under the
Platform.do masthead.
actions.do serves — the batch sibling holding the response grain is
live, titled "Orchestrate Complex Workflows" under the Platform.do
masthead.
platform.do serves — the operator's front door, whose own record
files this primitive's layer under the same claim discipline.
Four ambers — each the exact distance between what serves and what this door intends to be. (The figures gate on the economics slide is the estate's standing stack#1 §A5 disclosure rule, carried by every record in the portfolio — an estate gate, not a fifth product amber.)
The books and the door disagree on scope: the estate's registry files this coordinate as "Webhook management / Webhooks delivered" (primitives/messaging, P1), while the live apex self-describes more broadly as "Event streaming, ingestion, and analytics for the .do platform." This record adopts neither by assertion — it describes what the apex serves and wears the filing seam here until the registry or the door is re-filed (database.do naming-seam precedent; queued in the doctrine doc).
The MCP capability listing this door serves names its server
events.do — the sibling bus coordinate the registry files as P0 and
implemented, whose own apex has no serving zone anywhere today (the
doctrine doc's no-zone queue). The bus's name answers at the webhook
door while its own door is dark. This record claims the tools as what
this door serves and nothing about events.do's own liveness; the claim
flips when the bus serves at its own name or the naming is re-filed.
The apex's own discover map posts POST https://webhooks.do/e as the
ingest endpoint. A cold, unauthenticated probe on 2026-07-31 received
a 500 — not a typed acceptance and not a typed refusal. A door whose
whole premise is answerable arrivals should refuse legibly; this
record says so rather than rounding the route up to served.
Metered per event is the intended model, and the rate card IS the pricing surface: it binds when it posts — not before, and never as prose in a deck. No figure is published or implied until then; the apex's "Starter" plan string is a filing artifact, not posted terms.
Primary motion is B2D: the buyer is a developer who evaluates in
the machine descriptor the apex already serves — no sales motion, no
demo call, no procurement. The motion is designed to convert at the
first delivered event, and that first-event step gates on the ingest
route answering in type: the same POST /e amber the seams slide
wears openly, stated here rather than run ahead of.
Secondary is B2A: the same door addressed by agents — and the
first step of that motion already serves, because /mcp returns a
capability listing to a caller with no login: search, count, SQL over
the event store. Purchase and settlement for the machine motion gate
on the rate card posting, exactly as the sibling records state for
theirs.
Layer-1 economics at the messaging grain: fixed cost is operating the membrane and the store; each additional event received is served at near-zero marginal cost, so blended margin improves with flow.
The arrival record is the economic design, not just the reliability design: receiving one more event costs approximately nothing, while every event kept makes the record — and the analytics, search, and SQL surfaces over it — more valuable to interrogate. Flow compounds in the tenant's favor and the operator's at once. And there is no regulatory floor anywhere in this function: nothing in receiving, keeping, or querying an event reserves a step for a statutory person, so the implementation mix migrates all the way to Code.
Event volumes, feed counts, and the internal-versus-external split are gated. Each figure publishes with its window and base or it does not publish.
every brand the estate launches emits and receives events on the estate stack — the inbound record grows with the portfolio’s own search process, structural before commercial; the volume roll publishes behind its stack#1 §A5 gate or not at all
an arrival kept is worth more the longer it is kept and the more feeds join it — search, count, and SQL over the store make the door the place questions get answered, and moving the record means abandoning the answers
the apex answers cold callers with a typed descriptor and the MCP surface serves agent tools today — when the buyer is an agent, being discoverable and interrogable IS the distribution channel
arrival, condition, and response are three primitives under one operator — composing them is native, and unbundling the arrival re-creates the ingestion practice the builder came here to delete
The claim ledger lives on the "What serves today" and seams slides — one posted chip per live door, one amber per gate, each stated once. This slide is the evidence in kind: what a machine actually receives when it resolves this primitive, retrieved cold on 2026-07-31 with no login and no signup.
The machine door's capability listing. GET https://webhooks.do/mcp returns this envelope (abridged — the api
block repeats the apex descriptor):
{
"data": {
"name": "events.do",
"version": "0.2.0",
"capabilities": {
"tools": [
{ "name": "events_search", "description": "Search events by type, name, source, namespace, or time range." },
{ "name": "events_count", "description": "Count events matching filters, optionally grouped by type/event/source/ns." },
{ "name": "events_sql", "description": "Run a raw SQL query against the events database." }
]
}
}
}
Note "name": "events.do" — the seam quoted as bytes rather than
restated as a chip: the MCP server behind this door carries the bus
coordinate's name, and the seams slide holds the gate that flips it.
An authenticated surface, refusing legibly. GET https://webhooks.do/webhooks answers in the same structured envelope
with an authentication challenge, and routes login to
https://id.org.ai/login — the estate's identity door, not a
dead end: that door's own liveness is posted as its own green Claim
on the "What serves today" slide, with its own evidence URL, not
inferred from this envelope. The envelope's shape is what the ingest
route's amber holds POST /e to: this door already knows how to
refuse in type; the gate is that the ingest path does it too.
The front door is webhooks.do — it serves today, and answers
machine callers cold.
If this was forwarded to you: webhooks.do is the inbound-event surface of the startups.studio estate's infrastructure layer — the messaging primitive that owns the arrival grain, shipped in a batch with triggers.do (the condition) and actions.do (the response), each door holding exactly one grain by rule. What is live is posted with a URL checked cold — the apex's typed descriptor, the MCP tools, the authenticated surfaces refusing legibly — and what is not is pending with the gate that flips it, including the four ambers it wears openly: the registry-vs-apex scope seam, the events.do naming seam, the ingest route's cold-probe behavior, and the rate card. Judge it by what is posted, and by how plainly it labels what is not.