EDI Transactions
Query the EDI transaction log surfaced by the B2B Manager dashboard.
Each record represents a single EDI document (one X12 transaction set or one EDIFACT message) that was processed through a Celigo flow. The envelope metadata (sender/receiver IDs, control numbers, document type, functional acknowledgement status) is extracted during flow execution and indexed so the B2B dashboard can render filterable activity lists.
Requires a B2B / EDI license on the account.
EDI transaction schema
Partially updates one or more EDI transaction records. Commonly used to update the faStatus field (functional acknowledgment status).
The endpoint is lenient — when the ediTransactions array is empty, missing, or contains IDs that don't match any existing records, the response is 200 with {"ediTransactions": []} rather than a 400. Callers should always supply fileType and a non-empty ediTransactions array for meaningful results.
EDI file type.
Updated transaction records.
Bad request. The server could not understand the request because of malformed syntax or invalid parameters.
Unauthorized. The request lacks a valid bearer token, or the provided token failed to authenticate.
Note: the 401 response is produced by the auth middleware before the
request reaches the endpoint handler, so it does not follow the
standard {errors: [...]} envelope. Instead the body is a bare
{message: string} object with no code, no errors array. Callers
handling 401s should key off the HTTP status and the message string,
not try to destructure an errors[].
PATCH /v1/ediTransactions HTTP/1.1
Host: api.integrator.io
Authorization: Bearer YOUR_SECRET_TOKEN
Content-Type: application/json
Accept: */*
Content-Length: 95
{
"fileType": "X12",
"ediTransactions": [
{
"_id": "69ca6b7a42f275a91eab88bd",
"faStatus": "accepted"
}
]
}{
"ediTransactions": []
}Returns EDI documents processed through B2B Manager flows, with envelope metadata (sender/receiver IDs, control numbers), document type, direction, and functional acknowledgement status. This is the data source behind the B2B Manager "Transactions" dashboard.
Results are cursor-paginated — when more records exist beyond limit, the response includes pageToken.next. Pass it back as pageToken in the next request to get the next page. The server caps limit at 1000.
Use fileType with a dated window (startDate/endDate) to keep result sets bounded. faStatus must be passed as an array when filtering. Unknown filter fields are silently ignored. To fetch the raw EDI file for a returned record, use POST /v1/jobs/{_flowJobId}/files/signedURL with the record's s3Key.
Filter for POST /v1/ediTransactions/query. All fields are optional.
Results are narrowed by fileType, interchangeSenderId,
interchangeReceiverId, documentNumber, faStatus, and the
startDate/endDate window. direction, documentType, and
_integrationId are accepted but not applied server-side (filter on those
client-side). Records come back newest-first by lastModified and are
cursor-paginated via pageToken.
EDI standard family. Defaults to X12 when omitted — set
fileType: EDIFACT explicitly to query EDIFACT records.
Filter by interchange sender ID — exact match against the record's
isaSenderId (X12 ISA06). Applied server-side.
1234567890Filter by interchange receiver ID — exact match against the record's
isaReceiverId (X12 ISA08). Applied server-side.
CELIGOLABZTransaction direction. Accepted by the endpoint but not applied as a server-side filter — the result set is unaffected; filter client-side.
EDI document type code. For X12 this is the numeric transaction-set ID
as a string (e.g. "850", "810", "856", "997"); for EDIFACT the
UNH01 message type (e.g. "ORDERS", "INVOIC", "DESADV", "CONTRL").
Accepted but not applied as a server-side filter — the result set is
unaffected; filter client-side.
850Business document number to filter on — matches the documentNumber
field extracted from the transaction set (e.g. a purchase-order number
from an 850's BEG03).
PO03302026AIntegration the transaction was processed by. Accepted but not applied as a server-side filter — the result set is unaffected; filter client-side.
66cc9b31f2be816bf9377036Lower bound of the lastModified window, as epoch milliseconds.
The CLI converts ISO-8601 date strings to epoch-ms before calling.
When omitted, the server applies an internal default window.
1742774400000Upper bound of the lastModified window, as epoch milliseconds.
Must be greater than startDate.
1745452800000Maximum number of records to return per page. Server-enforced
range is 1–1000.
When more records exist beyond the limit, the response includes a
pageToken.next cursor for the next page.
100Opaque cursor from a previous response's pageToken.next. Pass
this value to retrieve the next page of results. Omit on the
first call.
One page of EDI transaction records. When more records exist beyond
limit, pageToken.next is included for the next page.
ediTransactions is [] when no records match — the endpoint does
not return 204 on empty results.
One page of EDI transaction records matching the request filter. When
more records exist beyond the limit, pageToken.next contains an
opaque cursor to pass back on the next request for the next page.
The request body failed validation.
Unauthorized. The request lacks a valid bearer token, or the provided token failed to authenticate.
Note: the 401 response is produced by the auth middleware before the
request reaches the endpoint handler, so it does not follow the
standard {errors: [...]} envelope. Instead the body is a bare
{message: string} object with no code, no errors array. Callers
handling 401s should key off the HTTP status and the message string,
not try to destructure an errors[].
POST /v1/ediTransactions/query HTTP/1.1
Host: api.integrator.io
Authorization: Bearer YOUR_SECRET_TOKEN
Content-Type: application/json
Accept: */*
Content-Length: 56
{
"fileType": "X12",
"limit": 100,
"startDate": 1742774400000
}{
"ediTransactions": []
}Returns functional acknowledgment (FA) details for a specific EDI transaction. FA details are only available for transactions with a "Rejected" status in B2B Manager.
The EDI transaction ID.
6a0377fcbfecf34a362e9be2EDI file type.
FA detail envelope.
The fileType query parameter is present but not a valid value, or the
transaction's FA status is not rejected (FA details are only available
for rejected transactions).
Unauthorized. The request lacks a valid bearer token, or the provided token failed to authenticate.
Note: the 401 response is produced by the auth middleware before the
request reaches the endpoint handler, so it does not follow the
standard {errors: [...]} envelope. Instead the body is a bare
{message: string} object with no code, no errors array. Callers
handling 401s should key off the HTTP status and the message string,
not try to destructure an errors[].
The EDI transaction was not found, or the fileType query
parameter was omitted entirely (the server treats a missing
fileType as a lookup failure rather than a validation error).
GET /v1/ediTransactions/{_ediTransactionId}/faDetails?fileType=X12 HTTP/1.1
Host: api.integrator.io
Authorization: Bearer YOUR_SECRET_TOKEN
Accept: */*
{
"faDetails": {
"Interchange Control Number": "000000005",
"Group": [
{
"Group Control Number": "1",
"Identifier Code": "FA",
"Transaction": [
{
"Transaction set Control Number": "0004",
"Document Type": "850",
"Errors": [
{
"Segment ID": "BEG",
"Element ID": "BEG03",
"Error message": "Mandatory data element missing",
"Data in error": "",
"Segment error": "4"
}
]
}
]
}
]
}
}Returns AS2 Message Disposition Notification (MDN) metadata for a specific EDI transaction record from the B2B Manager dashboard. The server reads the stored MDN artifact associated with the transaction and returns its raw body text together with a parsed disposition classification.
Get _id from a record returned by POST /v1/ediTransactions/query.
The EDI transaction ID.
6a0377fcbfecf34a362e9be2MDN metadata for the transaction.
AS2 Message Disposition Notification (MDN) metadata for an EDI transaction. The server reads the stored MDN artifact and returns the raw status message body together with a parsed disposition classification.
Full raw MDN body text, including the MIME headers and the Disposition:
line from the disposition-notification part.
Timestamp of the stored MDN artifact — its last-modified time when
available, otherwise the transaction's lastModified.
2026-05-21T21:32:52.000ZDisposition classification parsed from the modifier on the Disposition:
header in mdnStatusMessage (the status token after the disposition
type, e.g. processed or processed/error).
Unauthorized. The request lacks a valid bearer token, or the provided token failed to authenticate.
Note: the 401 response is produced by the auth middleware before the
request reaches the endpoint handler, so it does not follow the
standard {errors: [...]} envelope. Instead the body is a bare
{message: string} object with no code, no errors array. Callers
handling 401s should key off the HTTP status and the message string,
not try to destructure an errors[].
The EDI transaction was not found, has no associated MDN artifact, or the MDN artifact is no longer available in storage.
An unexpected error occurred while retrieving the MDN.
GET /v1/ediTransactions/{_ediTransactionId}/mdn HTTP/1.1
Host: api.integrator.io
Authorization: Bearer YOUR_SECRET_TOKEN
Accept: */*
{
"mdnStatusMessage": "------70B008BC93BAB50F580B205FC5CEF948\nContent-Type: multipart/report;Report-Type=disposition-notification;boundary=yFK5DJ9f\n\n--yFK5DJ9f\nContent-Type: text/plain\nContent-Transfer-Encoding: 7bit\n\nThe EDI message has been received successfully.\n--yFK5DJ9f\nContent-Type: message/disposition-notification\nContent-Transfer-Encoding: 7bit\n\nReporting-UA: integrator.io\nOriginal-Recipient: rfc822; partner-as2-id\nFinal-Recipient: rfc822; partner-as2-id\nOriginal-Message-ID: <message-id@integrator.io>\nDisposition: automatic-action/MDN-sent-automatically;processed\nReceived-Content-MIC: jVA1LAPZqJjQBEs/yBmHe/T3wwqMlJlh4gpLSdjO9U8=, sha256\n\n--yFK5DJ9f--",
"mdnTimestamp": "2026-05-21T21:32:52.000Z",
"mdnDisposition": "processed"
}Downloads the raw EDI file content for a specific document number.
The documentType query parameter is required and must be the EDI document type code — for X12, the numeric transaction-set ID as a string (e.g. 850, 810, 856, 997); for EDIFACT, the UNH01 message type (e.g. ORDERS, INVOIC, DESADV, CONTRL).
The server uses documentType + documentNumber together to locate the transaction record and return the associated raw EDI file.
Get documentNumber and documentType from a transaction record returned by POST /v1/ediTransactions/query. Alternatively, download via POST /v1/jobs/{_flowJobId}/files/signedURL using the s3Key from the transaction record.
The business document number that identifies the EDI transaction
(e.g. a purchase-order number from an 850's BEG03). Matches the
documentNumber field on an EDI transaction record.
PO03302026AThe EDI document type code. For X12, this is the numeric
transaction-set ID as a string (e.g. 850, 810, 856, 997).
For EDIFACT, this is the UNH01 message type (e.g. ORDERS,
INVOIC, DESADV, CONTRL).
Values like X12 or EDIFACT are not valid here — those
identify the EDI standard family, not the document type.
{"value":"850","summary":"X12 Purchase Order"}Raw EDI file content.
The request failed validation.
Unauthorized. The request lacks a valid bearer token, or the provided token failed to authenticate.
Note: the 401 response is produced by the auth middleware before the
request reaches the endpoint handler, so it does not follow the
standard {errors: [...]} envelope. Instead the body is a bare
{message: string} object with no code, no errors array. Callers
handling 401s should key off the HTTP status and the message string,
not try to destructure an errors[].
No transaction was found matching the provided document type and document number combination.
GET /v1/edi/documents/{documentNumber}/ediFile?documentType=text HTTP/1.1
Host: api.integrator.io
Authorization: Bearer YOUR_SECRET_TOKEN
Accept: */*
textLast updated
Was this helpful?