E-commerce Event Ingestion Integrity Automation: Zero Events, Since the Pipeline Existed
A write that fails with an error nobody was reading
A database rejecting an insert because a column name does not exist is about as loud an error as a database can produce — the problem is not the error's volume, it is whether anything downstream is listening for it. When a calling function fires the write and moves on without inspecting the response, a rejected insert and a successful one look identical from every vantage point a person or a dashboard would normally check: the request completed, the screen advanced, the log stayed quiet. The only place the truth lived was the one table nobody was querying directly.
How the underlying problem shows up before you fix it
An ingestion endpoint writes a new record using field names chosen at the time the endpoint was built, with nothing verifying those names still match the table's actual, current columns.
A database insert is rejected outright, and the calling code does not check the response — so a request that accomplished nothing and a request that succeeded return the identical "everything is fine" signal to whoever is watching.
Every downstream automation that depends on a specific kind of event — an abandoned cart, a completed purchase — sits configured, active, and completely idle, because the event it is waiting for has never once actually arrived.
A build, a typecheck, and an automated test suite all pass cleanly, because a mocked database client or test double accepts any object shape handed to it, and none of them know what the real, live schema actually requires.
The symptom that would normally catch this — a person noticing a specific automation never runs — has no obvious cause to investigate, because the automation itself is configured correctly; the event that should trigger it is what never shows up.
How a schema-comparison gate found what tests could not, and what the production probe confirmed
The store-event ingestion function sent two fields under names that made intuitive sense on their own — a bare name for the event, a bare category for it — but the actual table storing these events uses more specific column names for both. Because the database enforces its own schema strictly, PostgREST (the layer translating the request into a database write) rejected every one of these inserts outright. The calling code, however, checked almost none of these responses, so the rejection was invisible from every angle except the one table that should have been filling up with rows and never did.
The defect was found by building something neither a test suite nor a typecheck could provide: a direct, automated comparison between what the code tries to write and what the live database schema actually allows. A snapshot of every real table's real column list — pulled directly from the database's own information schema, not from any file describing an intended or assumed design — became the source of truth a dedicated check runs every insert and upsert against. Proving the check works meant deliberately reintroducing the original wrong field name and confirming the check turns red specifically because of that mismatch, not by coincidence.
Once the two field names were corrected to match the real table, a direct production probe confirmed the fix rather than merely asserting it: a real, live event was sent through the same ingestion path, and it was measured landing in the actual table, with the table's own daily event counter incrementing by exactly one in response. That confirmation matters specifically because the entire original defect was invisible from every layer except the database's own state — the same discipline that found the bug (checking the real, live thing rather than trusting that a build passing means the feature works) is what closes the loop on the fix.
What is actually built today
Centriu Flow's store-event ingestion endpoint writes using the correct, real column names for a store event's name and category, verified against the live database schema.
A dedicated automated gate compares every database insert and upsert in the codebase against a snapshot of the real, live schema pulled directly from the database's own information schema — not from a file describing an assumed design.
The schema snapshot is meant to be regenerated after every migration, keeping the comparison current rather than checking against a schema that can drift out of date on its own.
The gate is proven by mutation: deliberately reintroducing a wrong field name turns the check red specifically because of that mismatch, confirming the check tests the right thing rather than passing by coincidence.
A direct production probe, run after the fix shipped, confirmed a real event lands in the correct table and its daily counter increments — verification against the live system, not only against a test double.
Every automation configured to trigger on a store event (an abandoned-cart follow-up, a post-purchase sequence) now receives the events it was always meant to receive, without any change to the automation's own configuration.
An abandoned-cart automation, correctly configured, waiting for an event that never came (illustrative framing of the actual measured finding)
A store connects its checkout flow to Centriu Flow and configures an automation to follow up whenever a cart is abandoned — the automation itself is set up correctly, active, and ready. Before the fix, the event meant to trigger it is sent to the ingestion endpoint, rejected by the database under the hood, and silently discarded; the automation never receives a single trigger, and nothing about its own configuration would reveal why. After the fix, the identical abandoned-cart event is written successfully, the store's daily event count reflects it, and the automation fires exactly as it was always configured to.
What changes operationally
Store events sent through Centriu Flow's ingestion path are now written under the correct column names and verified against the live database schema before shipping — closing a gap where zero e-commerce events had ever been successfully recorded since the pipeline existed, and every automation depending on one had never fired.
When this is not the right fit
This automation governs whether a store event is correctly written to Flow's own database — it does not diagnose or fix a problem in how a store's own checkout platform sends events to Flow in the first place, and it does not retroactively create events for the period before this fix shipped.
Trusting that a passing test proves a feature works vs. checking the live schema directly
A green test suite and a clean build are real, valuable signals — and neither one can catch a defect whose entire failure mode lives inside how a mocked database client behaves differently from a real one. Centriu's fix adds exactly the check that closes that specific gap: a comparison against the database's own live, current schema, which cannot be fooled by a test double that accepts anything handed to it.
Related systems
Main system: Centriu Flow.
What it does NOT do
- Does not retroactively create or backfill any store event that failed to record before this fix shipped — the correction applies to writes going forward.
- Does not diagnose problems in how a store's own e-commerce platform or checkout flow sends events to Flow — it governs what happens once an event reaches Flow's own ingestion endpoint.
- Does not guarantee every possible store-event type is captured — this fix corrects the specific field-name mismatch found and measured in this investigation.
- Does not change how an automation itself is configured or triggered — the fix ensures the event an automation is waiting for actually gets recorded, not how the automation responds to it.
- Does not replace a merchant's own monitoring of whether their specific automations are running as expected.
- Does not claim every schema-mismatch defect in Flow has been found by this one fix — the dedicated comparison gate now runs on every future insert and upsert, but this specific fix covers only the store-event path.
Security and governance
The schema-comparison gate reads the live database's own information schema to build its reference snapshot, and enforces no changes to access control on its own; every event ingested remains scoped to the submitting account. Any business or customer data referenced remains subject to Brazil's LGPD (Law No. 13,709/2018). Full detail on access control lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Why did event ingestion fail with no visible error?
The database rejected every insert outright because the field names did not match its real columns, but the calling code did not check that rejection — so the request appeared to succeed from every angle except the database's own actual state.
How long had this been broken?
Since the ingestion path first existed — the measured finding was that zero real e-commerce events had ever been successfully recorded through it.
How was the fix actually verified, not just asserted?
A direct production probe sent a real event through the corrected path and confirmed it landed in the real table, with the table's own daily counter incrementing by exactly one.
What stops this class of defect from happening again?
A dedicated automated gate now compares every database write in the codebase against a live snapshot of the real database schema, proven by deliberately reintroducing a wrong field name and confirming the gate catches it.
Does this affect automations already configured before the fix?
No configuration change is needed — any automation already set up to trigger on a store event now receives the events it was always meant to receive.
What does Centriu Flow cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Flow verifies every store event actually gets recorded
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.