# EDI Transactions

Every EDI document that enters or leaves Tediware is recorded as a transaction: the direction, the sender and receiver identifiers, the control numbers, and the trace GUID linking it to its processing run. For outbound documents, Tediware also tracks whether the partner has acknowledged them with a 997, so you can find documents that are still waiting on an acknowledgment.

Transaction records are retained for 45 days.

Both endpoints on this page cover your whole organization, so they require a standard API key. Sandbox keys cannot reach them.

## List EDI Transactions

```
GET /platform/edi_transactions
```

Returns a paginated list of EDI transactions for your organization, ordered by most recent first.

Query parameters:

- `incoming`: `true` for documents received from partners, `false` for documents you sent
- `transaction_set_identifier`: filter by transaction set code, such as `850` or `856`
- `trace`: filter by trace GUID to find the transactions from a single processing run
- `ack_status`: filter by 997 acknowledgment state (see below)
- `limit`: number of transactions per page (default 50, maximum 100)
- `cursor`: pagination cursor from a previous response

The `ack_status` parameter accepts:

- `unacknowledged`: outbound documents still waiting for a 997 from the partner
- `acknowledged`: documents the partner has answered with a 997, whether accepted or rejected
- `accepted`: documents the partner's 997 accepted
- `rejected`: documents the partner's 997 rejected

An unrecognized `ack_status` or `incoming` value returns a `400` error.

The response includes an `ediTransactions` array and a `pagination` object:

```json
{
  "ediTransactions": [
    {
      "id": "4c2021f8-8310-4628-80f9-b578d4d68e11",
      "incoming": false,
      "transactionSetIdentifier": "850",
      "senderExtid": "YOURID",
      "senderQualifier": "ZZ",
      "receiverExtid": "PARTNERID",
      "receiverQualifier": "ZZ",
      "interchangeControlNumber": "1042",
      "groupControlNumber": "1043",
      "transactionSetControlNumber": "1043",
      "traceGuid": "5ab72145-4a4b-40f6-95de-e2579f163f79",
      "acknowledgmentStatus": "unacknowledged",
      "resendCount": 1,
      "lastResentAt": "2026-07-02T09:14:07.881Z",
      "createdAt": "2026-07-01T14:22:33.260Z",
      "updatedAt": "2026-07-01T14:22:33.260Z"
    }
  ],
  "pagination": {
    "hasMore": true,
    "nextCursor": "MjAyNi0wMy0zMFQxNDoyMjozMy4yNjAwMDBafDRjMjAyMWY4..."
  }
}
```

`acknowledgmentStatus` is `"accepted"`, `"rejected"`, or `"unacknowledged"`. It is `null` when no acknowledgment is expected: inbound documents, 997s and 999s themselves, documents sent to partners with acknowledgment tracking turned off, and documents sent before tracking was enabled. Acknowledgment tracking can be turned off per partner on the partner's settings page, for partners that do not send 997s.

`resendCount` is how many times this transaction has been resent, and `lastResentAt` is when the most recent resend ran (`null` when it has never been resent). Both count attempts, not confirmed deliveries: a resend that reached the partner's server and failed there still increments the count, and leaves an error result on the trace.

Cursor-based pagination works the same way as the results endpoint: when `hasMore` is `true`, pass `nextCursor` as the `cursor` parameter in your next request.

```bash
# Outbound documents still waiting on a 997
curl "https://tediware.com/platform/edi_transactions?ack_status=unacknowledged" \
  -H "Authorization: Key your-api-key-here"

# Everything a partner rejected in the last pages of traffic
curl "https://tediware.com/platform/edi_transactions?ack_status=rejected&limit=100" \
  -H "Authorization: Key your-api-key-here"
```

## Resend an Outbound Transaction

```
POST /platform/edi_transactions/:id/resend
```

Delivers a past outbound transaction to your partner again, exactly as it was sent the first time. Tediware re-uploads the stored EDI byte for byte and keeps the original ISA, GS, and ST control numbers. It does not rebuild the document, so your partner receives the original bytes even if the mapping or implementation has changed since the original send.

Resend when the first delivery did not reach your partner: no acknowledgment came back, the partner says they never received the document, or the delivery failed at the time.

A resend reuses the original transaction. Tediware creates no second transaction record, you are not billed again, and the new delivery and its logs land on the original `traceGuid`.

Because the resent document carries the original control numbers, a partner that already received the first copy usually recognizes it as a duplicate and ignores it. Some partners reject a repeated or out-of-sequence control number instead, so whether a resend is accepted depends on the partner.

The request takes no body.

### Success Response

On acceptance, the API returns `202`:

```json
{
  "message": "Resend started",
  "ediTransactionId": "4c2021f8-8310-4628-80f9-b578d4d68e11"
}
```

`202` means the resend started. Tediware runs the upload and its retries in the background after answering, so the response does not confirm delivery.

To see the resend land, poll the list endpoint filtered to this transaction's trace and watch `resendCount` rise:

```bash
curl "https://tediware.com/platform/edi_transactions?trace=5ab72145-4a4b-40f6-95de-e2579f163f79" \
  -H "Authorization: Key your-api-key-here"
```

A resend of an auto-generated 997 also publishes a new success entry to the feed. A resend of a flow-delivered business document does not: it republishes the same delivery result, which the feed collapses, so `resendCount` is how you confirm that one.

### Example Request

```bash
curl -X POST "https://tediware.com/platform/edi_transactions/4c2021f8-8310-4628-80f9-b578d4d68e11/resend" \
  -H "Authorization: Key your-api-key-here"
```

### Error Responses

```
| Status | Code                    | Cause                                                                     |
|--------|-------------------------|---------------------------------------------------------------------------|
| 401    | unauthorized            | The API key is missing or invalid                                         |
| 403    | forbidden               | The key is a sandbox key. A resend puts a document on a partner's wire, so it needs a standard key |
| 404    | not_found               | No transaction with that id exists in your organization                   |
| 422    | not_outbound            | The transaction is inbound. Only documents you sent can be resent         |
| 422    | content_unavailable     | The stored document is gone. Delivered documents are kept for 45 days, so the transaction record can outlive the bytes |
| 422    | delivery_node_missing   | The flow node that delivered the document no longer exists                |
| 422    | not_flow_delivered      | The document did not go out through an outbound flow. This applies to an automatic 997 sent before Tediware began storing a copy of each acknowledgment it generates |
| 422    | delivery_target_missing | The connection or webhook the document was delivered to has been removed  |
| 429    | rate_limited            | More than 10 resends in a minute on this key                              |
```

The list endpoint does not report whether a given transaction can be resent. Attempt the resend and handle the `422` codes, each of which names the reason.

Automatic 997 acknowledgments that Tediware generates for you can be resent like any other outbound document, provided a stored copy still exists. A resent acknowledgment goes out under a fresh filename and a fresh AS2 message id, so the partner's duplicate detection does not discard the copy you are chasing.

Resend has its own rate limit of 10 requests per minute per key, tighter than the 240 per minute that the read and write endpoints share. Hammering it is visible to your partner as a flood of duplicate documents.