Skip to content

Duplicate Handling

The uniqueTransmissionID element is the key mechanism for safe retry handling in the eXite® Web Service API.

How it works

Always include uniqueTransmissionID

If a request fails without a confirmed response (network timeout, connection reset, etc.), retry with the same uniqueTransmissionID. eXite® will detect the duplicate and return the original result without re-processing the invoice.

The server checks every incoming uniqueTransmissionID:

  1. Not seen before → request is processed normally.
  2. Seen before, original still processing → returns UTIDPROCESSING. Wait and retry.
  3. Seen before, original completed → returns UTIDREUSED + the original response. Nothing is re-processed.

Format requirements

Property Requirement
Length 8–40 characters
Allowed characters Alphanumeric (A-Z, a-z, 0-9) and -
Recommended format UUID v4 (e.g. f88b3b23-78ff-495a-a3ea-a2a4e4a988a1)
Uniqueness scope Must be unique per operation type (send vs. receive vs. status). The same ID may be reused across different operation types.

Retry flow

Client                          eXite®
  │                               │
  │── sendInterchange (ID=abc) ──►│
  │                               │  (network failure — no response received)
  │                               │
  │── sendInterchange (ID=abc) ──►│  ← same ID, retry
  │◄── UTIDREUSED + orig response ┤
  │                               │  (invoice NOT sent twice)

UTIDPROCESSING — request still in progress

In rare cases (very large batches, slow processing), a retry may arrive while the original request is still being handled. eXite® responds with:

<eXite:sessionProcessing>
  <eXite:sessionProcessingInformation
    eXite:sessionProcessingInformationCode="UTIDPROCESSING">
    WARNING: Previous request with this ID is still being processed. Please retry later.
  </eXite:sessionProcessingInformation>
</eXite:sessionProcessing>

In this case the response body will be empty. Wait a short interval and retry with the same ID.