Ingest transactions

Transactions reach the platform by batch ingest or by the transaction API. Both write the same rows into the same monthly-partitioned table, and nothing downstream can distinguish them — a monitoring rule behaves identically whichever path the activity arrived on.

What makes a retry safePermalink to this section

A caller supplies its own reference for each transaction. A retry carrying a reference already seen is not a second transaction — this is what lets a client that timed out mid-batch simply send the batch again rather than reconcile it first.

Reading a rejectionPermalink to this section

Ingest validates before it writes. A rejected item names the field and the reason in the problem-details body; the rest of the batch is unaffected. What ingest does not do is decide anything about the transaction beyond whether it is well-formed — risk, monitoring and alerting happen after the row exists.