# Traces A trace is one processing run. Every document that moves through Tediware gets a `traceGuid`, and every submission receipt, webhook payload, feed entry, result and log line carries it. This endpoint assembles the whole run into one response: the transactions on it, what each step produced, the feed entries it published, the logs it wrote, every artifact it stored, and whether it has finished. It is the endpoint to reach for after a submission, and the one to reach for when something went wrong and you do not yet know where. Requires a standard API key: a trace covers your whole organization. Sandbox keys cannot reach it. ## Get a Trace ``` GET /platform/traces/:traceGuid ``` ```json { "traceGuid": "5ab72145-4a4b-40f6-95de-e2579f163f79", "processing": false, "ediTransactions": [ { "id": "4c2021f8-8310-4628-80f9-b578d4d68e11", "direction": "inbound", "incoming": true, "partnerKey": "ACME", "transactionSetIdentifier": "850", "interchangeControlNumber": "1042", "traceGuid": "5ab72145-4a4b-40f6-95de-e2579f163f79", "acknowledgmentStatus": null, "createdAt": "2026-07-01T14:22:33.260Z" } ], "results": [ { "id": "1dc6a6fb-abcd-1234-ef56-789012345678", "nodeName": "EDI to JSON", "nodeId": "3e5c9017-aaaa-bbbb-cccc-ddddeeeeffff", "status": "success", "traceGuid": "5ab72145-4a4b-40f6-95de-e2579f163f79", "createdAt": "2026-07-01T14:22:33.401Z", "detail": { "direction": "inbound", "partner": { "key": "ACME" } } } ], "feedEntries": [ { "id": "fe10c8a2-...", "direction": "inbound", "status": "success", "partnerKey": "ACME", "resultId": "1dc6a6fb-abcd-1234-ef56-789012345678", "traceGuid": "5ab72145-4a4b-40f6-95de-e2579f163f79", "createdAt": "2026-07-01T14:22:35.900Z" } ], "logs": [ { "level": "info", "message": "Extracted 1 transaction set", "nodeName": "EDI to JSON", "createdAt": "2026-07-01T14:22:33.402Z" } ], "artifacts": [ { "id": "b613c64c-dcba-4321-fe65-987654321098", "usage": "input", "contentType": "application/edi-x12", "filename": "850_4471.edi", "resultId": "1dc6a6fb-abcd-1234-ef56-789012345678", "nodeName": "SFTP Fetch" } ] } ``` `results`, `feedEntries` and `logs` are all oldest first, so the response reads in the order the run happened. `ediTransactions` carries the list shape from the [EDI Transactions](/resources/api-docs/edi-transactions) page, and `results` the shape from [Results and Artifacts](/resources/api-docs/results). Fetch either individually when you want the full detail; this response is the map. ## Each artifact once, with the step that produced it `artifacts` is every artifact on the run listed exactly once, each carrying the `resultId` and `nodeName` that produced it. That labelling is the point. An artifact pointer accumulates down a flow, so a late step's own `detail.artifacts` repeats everything written before it, and collecting them across a run gives you the same file many times over with nothing saying which step wrote it. A pointer's first appearance in creation order is its producer, and that is what this array records. For a trace that produced an automatic 997, this is how you tell the acknowledgment from the document it acknowledged without reading filenames. ## processing `processing` is `true` while the run is still working, and `false` once every step that will run has run. Poll it after a submission rather than watching the log stop growing: a log that has paused for a second looks the same as one that has finished. Nothing stores a running state, so this is derived from the flow graph. Each step writes its result and enqueues the steps after it, so work remains exactly while some step has written more results than the steps after it have taken. It is counted per result rather than per step, because a splitter writes one result per transaction set and the sets flow on one at a time. An errored result ends the run. The poll-only terminal writes no result at all, so its work is read from the success feed entry it publishes instead. A submission typically settles in a few seconds. A trace still `processing` after a minute is worth investigating: read its logs, which may name a step waiting on a partner's server. ## The log visibility lag `logs` here follow the same rule as `GET /platform/logs`: entries younger than about five seconds are withheld. A log line is committed after its timestamp, and a reader who saw "that is everything" and then watched an older line appear would rightly stop trusting the endpoint, so the endpoint waits instead. The practical effect is that the tail of a run that just finished takes a moment to appear. `processing: false` with a short log is a run that has finished and whose last lines have not surfaced yet. ## Example Request ```bash curl "https://tediware.com/platform/traces/5ab72145-4a4b-40f6-95de-e2579f163f79" \ -H "Authorization: Key your-api-key-here" ``` Polling a submission to completion: ```bash TRACE=$(curl -s -X POST "https://tediware.com/platform/partners/ACME/ts/856" \ -H "Authorization: Key $KEY" -H "Content-Type: application/json" \ -d '{"contents": {...}}' | jq -r .traceGuid) until [ "$(curl -s "https://tediware.com/platform/traces/$TRACE" \ -H "Authorization: Key $KEY" | jq -r .processing)" = "false" ]; do sleep 2 done ``` Give that loop a timeout of its own, and treat the timeout as "unknown" rather than as a failure. ## Error Responses ``` | Status | Code | Cause | |--------|--------------|-----------------------------------------------------------------------| | 401 | unauthorized | The API key is missing or invalid | | 403 | forbidden | The key is a sandbox key. This endpoint covers the whole organization | | 404 | not_found | Nothing in your organization carries that trace GUID | ``` A `404` means the GUID resolves to nothing in your organization: a typo, a trace from another organization, or one whose records have aged out. A GUID a submission just handed you always resolves, because the entry step's result is written before the submission answers. The lag you will see instead is in `logs`, for the reason above.