---
title: "Generate the ANSI ASC X12 997 Functional Acknowledgment for..."
method: POST
path: "/api/edi/ack"
tags: ["edi"]
---

# Generate the ANSI ASC X12 997 Functional Acknowledgment for...

`POST /api/edi/ack`

## Request

- Base URL: `https://2s.io`
- URL: `https://2s.io/api/edi/ack`
- Auth: API key in header `PAYMENT-SIGNATURE`

Generate the ANSI ASC X12 997 Functional Acknowledgment for a received EDI interchange. POST { edi } with the raw inbound interchange text (the 850/810/856/etc. you received); returns the ready-to-send 997 in meta.ack — sender/receiver mirrored back, delimiters echoed, one ST(997) per inbound functional group with correct AK1 (functional id + group control number), AK2/AK5 per transaction set, and AK9 with accurate included/received/accepted counts. Set status to control the response: A=Accepted (default), E=Accepted with errors, P=Partially accepted, R=Rejected, M/W/X=authentication/security rejection. Deterministic, no external calls. This is the reply leg of EDI: every transaction set you receive is supposed to be acknowledged, and assembling a valid 997 (especially the AK9 counts) is exactly the fiddly envelope bookkeeping agents shouldn't hand-roll.

## Query parameters

- `trial` 1

## Request body

- object
  - `edi` string, required: Edi.
  - `status` 'A' | 'E' | 'P' | 'R' | 'M' | 'W' | 'X': Filter results by status.
  - `controlNumber` string: Control number.

## Other responses

- `200` (unresolved $ref)
- `400`: Invalid request — not charged. error.code: BAD_REQUEST or INVALID_PARAM (parameter validation; error.details.issues lists each problem), MALFORMED_JSON, or a request-specific code. Other client errors: 405 METHOD_NOT_ALLOWED (wrong verb; see the Allow header), 413 PAYLOAD_TOO_LARGE.
- `402`: Payment required. Body is the x402 PaymentRequirements envelope with a multi-network accepts array; the per-call price is in accepts[].amount (and on the operation as x-2s-price). Sign for whichever rail you hold USDC on (EIP-3009 for Base, partial SPL transfer for Solana) and retry with the PAYMENT-SIGNATURE header (X-PAYMENT also accepted for v1 clients). Also PAYMENT_SETTLE_FAILED (error envelope) when a verified payment failed to settle: error.details.chargeStatus is "not_charged" (retry with a fresh payment) or "unknown" (the authorization may still settle before its deadline — check it before retrying).
- `429`: Too many requests — RATE_LIMITED: our per-IP / per-payer limiter. Not charged; retry after Retry-After.
- `5XX`: Server-side failure. 500 INTERNAL: unexpected error; quote error.errorId (also the X-2s-Error-Id header). 502 UPSTREAM_UNAVAILABLE (or another UPSTREAM_* code): the data provider failed — composite endpoints refuse unbilled when every source fails. 503 SERVICE_PAUSED: endpoint paused by the operator kill switch, retry after Retry-After; 503 SPEND_CAP: daily upstream budget exhausted. 504 UPSTREAM_TIMEOUT. Not charged.

---

[API](https://skmtc.dev/2s-io/apis/2s-the-most-everything-api.md) · [All operations](https://skmtc.dev/2s-io/apis/2s-the-most-everything-api/llms.txt) · [OpenAPI document](https://skmtc.dev/2s-io/apis/2s-the-most-everything-api/revisions/da4c5caf686e?raw)