# Submitting Outbound EDI When sending EDI to a trading partner, your system submits JSON data to this endpoint. Tediware converts it to EDI using the partner's mapping and implementation, then delivers the EDI document to the partner's connection. Processing is asynchronous -- the API returns immediately with a trace identifier and control numbers. When delivery completes, your outbound webhook is called; if an error occurs, your error webhook is called instead. See the Overview page for the full outbound data flow. ## Prerequisites Four things must be in place on the partner before a submission can succeed. Each has its own error if it is missing, so you can work through them in order. 1. **An outbound transaction setting** for the code you are sending. This is what declares "this partner receives 856s from us". Add it on the partner's Transaction Sets card. 2. **An implementation or a mapping** on that setting. The setting on its own only declares intent; the implementation is the partner's EDI guide, and a mapping converts your JSON shape into it. Until one is attached, the setting is not ready and no EDI can be produced. 3. **An outbound flow set to Active.** The transaction setting says what to send; the flow says how to build and deliver it. A flow that exists but is in Draft does not serve the endpoint. 4. **Envelopes assigned to the partner**, internal and external. These supply the ISA sender and receiver identifiers. After changing any of this, rebuild the flow so the change takes effect. The endpoint runs the flow as it was last built, so a configuration change that has not been rebuilt is invisible to it. None of this is checked when you create the partner, and a missing piece is not an error until you send. That is deliberate: a partner is usually set up over several sittings. It does mean the first submission for a new partner is where you find out what is left to do. ## Endpoint ``` POST /platform/partners/:key/ts/:code ``` - `:key` -- the partner's unique key (e.g., `ACME`). Visible on the partner detail page and set when the partner is created. Case-insensitive: `acme` and `ACME` resolve to the same partner. - `:code` -- the X12 transaction set code (e.g., `810`, `850`, `856`). Must match an outbound transaction setting configured on the partner. ## Request Body The request body is JSON with the following fields: - `contents` (required) -- the transaction data to convert. The structure depends on your mapping configuration for this partner and transaction set. - `filename` (optional) -- a custom filename for the generated EDI file. Must contain only letters, numbers, underscores, periods, and dashes, with a maximum length of 128 characters. If omitted, a random filename is generated. - `overrides` (optional) -- envelope identifier overrides. Use these to override the sender and receiver identifiers that would normally come from your partner's envelope configuration: - `interchangeSenderId` -- override the ISA sender ID - `interchangeSenderQualifier` -- override the ISA sender qualifier - `interchangeReceiverId` -- override the ISA receiver ID - `interchangeReceiverQualifier` -- override the ISA receiver qualifier ## Success Response On success, the API returns `200` with the control numbers assigned to the transmission and a trace identifier: ```json { "message": "Processing queued", "interchangeControlNumber": 1042, "groupControlNumber": 1042, "traceGuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890" } ``` - `interchangeControlNumber` -- the ISA control number assigned to this interchange. - `groupControlNumber` -- the GS control number assigned to this functional group. This will also be the transaction set (TS) control number. - `traceGuid` -- a unique identifier that links all processing results for this submission. Use it to query results or look up the trace in the application UI. ## Example Request ```bash curl -X POST "https://tediware.com/platform/partners/ACME/ts/810" \ -H "Authorization: Key your-api-key-here" \ -H "Content-Type: application/json" \ -d '{ "contents": { "invoiceNumber": "INV-2026-001", "invoiceDate": "2026-03-30", "totalAmount": 1500.00, "lineItems": [ { "quantity": 10, "unitPrice": 150.00, "description": "Widget A" } ] }, "filename": "invoice-001.edi" }' ``` ## Error Responses ``` | Status | Code | reason | Cause | |--------|---------------------|---------------------------|--------------------------------------------------------------------| | 400 | missing_parameter | | The contents field is missing or null | | 400 | invalid_filename | | The filename contains invalid characters or exceeds 128 characters | | 400 | invalid_envelope | | The envelope configuration is incomplete or invalid | | 401 | unauthorized | | The API key is missing or invalid | | 404 | not_found | partner | The partner key does not match any partner in your organization | | 404 | not_found | transaction_set | The transaction set code is not configured for outbound on this partner | | 422 | configuration_error | transaction_set_not_ready | The setting exists but has no implementation or mapping | | 422 | configuration_error | flow_inactive | The partner has no outbound flow set to Active | | 422 | configuration_error | missing_endpoint_node | The flow has no partner endpoint node | | 422 | configuration_error | ambiguous_endpoint_node | The flow has more than one matching node | | 422 | configuration_error | missing_external_envelope | The partner has no external envelope assigned | | 422 | configuration_error | missing_internal_envelope | The partner has no internal envelope assigned | ``` `code` names the class of failure and `reason` names the specific condition, so you can branch on either. The code tells you whether to retry: **400 and 404 will never succeed on an unchanged resend**, because the payload or an identifier is wrong. **A 422 `configuration_error` will succeed** once someone completes the prerequisite it names, with no change to your request. Branch on the code rather than the status, since other endpoints return `422` under codes that no amount of retrying will clear. The `invalid_envelope` 400 is the one judgment call in the table: it can be caused by the `overrides` you sent, so it is treated as a problem with the request. ## Resending a Document You Already Sent This endpoint always builds and sends a new document with new control numbers. To deliver a document you already sent a second time, byte for byte and under its original control numbers, use `POST /platform/edi_transactions/:id/resend` instead. See [EDI Transactions](/resources/api-docs/edi-transactions) for when a resend is possible and what it does to the transaction record.