Tracking 997 acknowledgments and a new API endpoint for your transactions

When you send a document to a trading partner, the transport doesn’t tell you much. The file left your system and landed on an SFTP server or crossed an AS2 connection, and that is the last thing you know for certain. Whether your partner’s system picked it up, parsed it, and accepted it is a separate question, and it is the question that actually matters, because a purchase order that was delivered but never processed looks exactly like one that was processed, right up until someone calls asking where their order is.

X12 has an answer for this: the 997 functional acknowledgment, a small document your partner sends back that says “I received your batch of transactions, and here is whether I accepted it.” The trouble is what most EDI setups do with 997s, which is nothing. They arrive, they get logged as one more inbound document, and nobody connects them back to the outbound documents they acknowledge. So the receipt you needed sits unread in a folder while you field the phone call anyway.

Tediware now makes that connection for you.

How it works

Say you send an 850 purchase order to a partner, and it goes out in a functional group with control number 1043. On the EDI Transactions page, that document now shows Awaiting 997 in a new 997 column.

Sooner or later (partners vary a lot on this, which is part of why tracking it matters) your partner’s system sends back a 997 containing something like:

AK1*PO*1043~
AK9*A*1*1*1~

The AK1 segment names the group being acknowledged, control number 1043, your 850. The AK9 carries the verdict, and A means accepted. Tediware reads both, matches the control number back to the document you sent, and the 850’s status flips to 997 accepted. If the partner had rejected it, you would see 997 rejected instead, and you could open the transaction to inspect the 997 they returned.

The page also gets a 997 filter, so you can answer the questions this data exists to answer: show me everything still waiting on an acknowledgment, or everything this partner has rejected.

Tracking is on by default for every partner. Some partners simply never send 997s, and for those you can turn it off on the partner’s configuration page (Track 997 acknowledgments for outbound), so their documents don’t sit in an Awaiting state that will never clear.

The new API endpoint

The EDI transaction log (what you see when you go to https://tediware.com/app/edi-transmissions) is now queryable over the API. GET /platform/edi_transactions returns your organization’s transaction records (retained for 45 days), with cursor pagination and filters for direction, transaction set, trace GUID, and acknowledgment state.

The query for getting a list of unacknowledged transactions:

curl "https://tediware.com/platform/edi_transactions?ack_status=unacknowledged" \
  -H "Authorization: Key your-api-key-here"

{
  "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",
      "createdAt": "2026-07-01T14:22:33.260Z",
      "updatedAt": "2026-07-01T14:22:33.260Z"
    }
  ],
  "pagination": {
    "hasMore": true,
    "nextCursor": "MjAyNi0wMy0zMFQxNDoyMjozMy4yNjAwMDBafDRjMjAyMWY4..."
  }
}

There it is: the 850 with group control number 1043, still waiting on its 997. The ack_status parameter takes unacknowledged, acknowledged, accepted, or rejected, and the acknowledgmentStatus field on each record reports the same states. The field is omitted when no acknowledgment is expected, which covers inbound documents, 997s themselves, and partners where you’ve turned tracking off.

Tediware doesn’t yet alert you when a document has been waiting too long. If you want that today, a scheduled job that runs the query above and complains about anything older than a day gets you there with very little code.

What it doesn’t cover yet

Partners who acknowledge with the 999 instead of the 997 (common in healthcare) aren’t correlated yet. The verdict is read from the group-level AK9, which maps one to one to your document because Tediware sends one transaction set per functional group. And documents you sent before this feature existed show no acknowledgment status, since there was nothing recording what they were owed at the time.

The full endpoint reference is in the API docs. If your partners have acknowledgment behavior that doesn’t fit what I’ve described, I’d genuinely like to hear about it: adrian@tediware.com.