# 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: its transactions, what each step produced, the feed entries it published, the logs it wrote, every artifact it stored, and whether it has finished. Requires a standard or read-only 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" } }, "payload": { "format": "json", "bytes": 5182 } } ], "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", "resultId": "1dc6a6fb-abcd-1234-ef56-789012345678", "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. Each log entry has the shape described on the [Logs](/resources/api-docs/logs) page. `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) plus a `payload` pointer on each row (below). Fetch either individually when you want the full detail; this response is the map. ## Payload pointers Each result carries `payload`: the `format` of the data that step produced and its size in `bytes`. The payload itself is not in this response, because every step keeps its own copy of the document and a large trace would run to megabytes. Read one with [`GET /platform/results/:id/payload`](/resources/api-docs/results). `payload` is `null` on a result that holds no data. A failed result carries `detail.incomingResultId`, the result whose payload the failing step received. That is where to look first when a step refuses a document: `detail.errors` says what was wrong, and the incoming payload shows the document it was wrong about. ## Each artifact appears 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. Use this array rather than collecting `detail.artifacts` from each result yourself. A result's `detail.artifacts` lists the artifacts from every step before it as well as its own, so collecting them across the run gives you the same file several times, with nothing saying which step wrote it. This array attributes each artifact to the first result it appears on, which is the step that produced it. 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. It stays `true` while any step has written a result that the next step has not yet picked up. That is counted per result, so when a run splits an interchange into several transaction sets, it stays `processing` until every set has gone through. A step that errors ends the run. A flow that delivers by polling has finished once its entry appears in the feed. 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.