Transactions and logging
Transaction identifiers, timing fields, context, and what Datastruct records
Every /data and /func call is one transaction. This reference defines its
identifier, timing, context, and recorded data.
Transaction identifiers
{ "transaction_id": "trx_01k2v8q9m7f3zb6cw4h5n0j1xd" }
The identifier is a trx_ TypeID backed by UUIDv7. It is opaque: do not parse
it or derive a timestamp. Every retry gets a new identifier. Include it in
support requests.
Identifier prefixes
| Prefix | Object |
|---|---|
trx_ |
Transaction |
org_ |
Organization |
wfl_ |
Workflow |
dfunc_ |
Data function |
crd_ |
Stored credential |
dsrc_ |
Data source |
dprv_ |
Data provider |
All identifiers are opaque.
Timing
| Field | Scope |
|---|---|
Top-level response_time_ms |
Whole service request |
status.<name>.response_time_ms |
One source or function |
Source timing includes credential resolution. Since /data runs sources in
parallel, total time is near the slowest source, not their sum. Service timing
excludes client-to-service network time.
Context
config.context accepts prod, test, or dev; default dev. It labels the
transaction and sets the default input/output redaction level. Send prod for
production traffic.
Recorded data
Transactions record the identifier, organization, workflow, context, run configuration, status, inputs, and outputs, subject to redaction.
| Redaction | Effect |
|---|---|
| Full | Replace every value and retain keys |
| Schema | Replace schema fields marked sensitive |
| None | Retain values |
Production context uses the strictest default. A function can declare an overriding level.
Confirmation needed: Confirm exact redaction defaults per context and the transaction retention period. Neither is safe to state from code alone.
Confirmation needed: Confirm whether customers can currently read transaction records through the console or an API. Until confirmed, integrators should retain their own operational logs.