> For the complete documentation index, see [llms.txt](https://docs.live-eo.com/tradeaware/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.live-eo.com/tradeaware/using-the-tradeaware-api/manage-your-transactions.md).

# Manage your transactions

Transaction Management provides a systematic way to link EUDR compliance data with the product level information required to evidence compliance with the Regulation in the form of a Due Diligence Statement (DDS) in the EU Information System (EU TRACES). It enables key information from your ERP, such as Purchase Orders and Sales Orders, to be captured in these DDS as well providing a way of managing linkages with existing DDS and connections between different product level documentation.

### What changed in the September 2026 release

* TRADE is no longer accepted as an activity type.
* Components accept supplementaryUnit and supplementaryUnitQualifier. Some HS codes require them.
* percentageEstimationOrDeviation applies to DOMESTIC transactions only.
* On GET /dds/fetch-dds-data, status is now returned with null values.

If you have an existing integration, see [Testing the reconnection](https://docs.live-eo.com/tradeaware/using-the-tradeaware-api/manage-your-transactions#testing-the-reconnection) before your next submission.

### :warning: Prerequisites

* Transaction Management is a premium feature in TradeAware. To use this functionality, your account must be enabled for transactions. If you do not have this enabled, contact your Customer Success Manager.
* Your business will also need to have an identifier added to the account details to submit a transaction to TRACES. This must be an EORI for import and export transactions but can be VAT for domestic (internal EU transactions). You can update this in your [Manage Account](/tradeaware/readme/getting-started.md) page.
* Your business will need to be connected to plots of the relevant commodity to submit a Transaction to TRACES. This can be done either through connected supplier businesses or through plots managed under your own business account (self-managed model).
* You will be able to see the data with your associated account on TRACES. By default the system is connected to the ACCEPTANCE testing system. Stay on ACCEPTANCE while testing and switch to PRODUCTION only when you are ready to submit legally valid due diligence statements.

### Overview

Transaction Management provides a way to link transaction data, such as Purchase Orders (PO) and Sales Orders (SO) to compliance data in TradeAware to create and manage Due Diligence Statements.

**Customers can:**

* **Manage Due Diligence Statements:** Link orders from your ERP system to compliance data in TradeAware.
* **Enhance Traceability**: Connect DDS compliance data to orders, streamlining regulatory reporting and audit preparation.
* **Automate Compliance Workflows**: Minimize manual data entry by automating key compliance and transaction workflows.

### Activity Types and Required Fields

⚠️ Note: The following table is intended as a quick reference for understanding the main differences between activity types. For the complete and up-to-date list of required fields, please refer to the[ API Reference](https://docs.live-eo.com/tradeaware/using-the-tradeaware-api/api-reference/transactions).

Each transaction contains one or more components, where each component represents a product or commodity line (HS code + quantity + unit + description). Depending on your business process, a component can be built using:

* Supplier-based traceability (one or more suppliers, with optional plot selection), and/or
* Upstream DDS reference traceability (one or more DDS references), and/or
* Self-managed plot traceability (plots managed under your own business account, without supplier IDs).

**Typical patterns by activity type**

<table data-header-hidden><thead><tr><th width="124.703125"></th><th width="244.3583984375"></th><th width="466.9482421875"></th></tr></thead><tbody><tr><td><strong>ActivityType</strong></td><td><strong>When to Use</strong></td><td><strong>Typical component inputs</strong></td></tr><tr><td><code>IMPORT</code></td><td>First placement of goods on the EU market from a third country</td><td>Supplier-based traceability (supplierBusinessId or supplierBusinessIds) + optional plotIds</td></tr><tr><td><code>EXPORT</code></td><td>Shipping goods from the EU to a non-EU country</td><td>Upstream DDS references (ddsReferences) are typical; supplier plots may be included for hybrid workflows where neededw</td></tr><tr><td><code>DOMESTIC</code></td><td>Processing goods within the EU (HS code change) or placing EU-produced goods on the market</td><td>Upstream DDS references (ddsReferences) are typical; supplier plots may be included for hybrid workflows where needed</td></tr></tbody></table>

Optional product information (components)\
`plotIds`, `namePairs`, `dateOfProduction`, `endDateOfProduction`, `customData`, `isGeoLocationConfidential`

⚠️ TRADE is no longer accepted. POST /transactions with activityType: "TRADE" returns: 400 Bad Request\
{ "message": \["activityType must be one of the following values: IMPORT, EXPORT, DOMESTIC"] } Trade transactions created earlier keep the status DEPRECATED. They remain readable through GET /transactions and GET /transactions/{id}, but no longer accept updates or submission.

### **Testing the reconnection**

Accounts are connected to the TRACES ACCEPTANCE environment by default, so you can run a full submission without filing anything legally binding. Stay on ACCEPTANCE while testing and contact your Customer Success Manager when you're ready to move to PRODUCTION.

1. Create a transaction — `POST /transactions`, returns 201 with status DRAFT.
2. Submit it — `PUT /transactions/{id}/submit`, returns 202 with status TO\_SUBMIT.
3. Poll — `GET /transactions/{id}`. The status moves TO\_SUBMIT → SUBMITTED → AVAILABLE, and the DDS reference and verification numbers appear once it is AVAILABLE. Submission is asynchronous; the Commission advises waiting at least 30 minutes after submitting before polling for status. If TRACES rejects the statement the status becomes ERROR and the reason is returned under dds.errors.
4. Retrieve it back — `GET /dds/fetch-dds-data?referenceNumber={ref}&verificationNumber={ver}`. is rate limited to 2 requests per 10 seconds per client. Responses carry X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers.

💡 Response change. On /`dds/fetch-dds-data` the status object is still present but its values are now null:  `"status": { "status": null, "date": null }`

The new EU API does not return a status for a DDS looked up this way. The field is kept so existing integrations don't break; populating it again is planned. Use GET /transactions/{id} for the status of transactions you filed yourself.

**What to check in your integration**

* You no longer send activityType: "TRADE".
* You send a supplementary unit for the HS codes that require one.
* You only send percentageEstimationOrDeviation on DOMESTIC transactions.
* Your code tolerates status.status being null on /dds/fetch-dds-data.

### List of Use Cases

1. Transaction Management for Operators (Activity: Import, Export, Domestic)
2. Managing Composite Products
3. Submitting Transactions to TRACES
4. Linking Transactional Data to Compliance Workflows (e.g. Batches, Shipments)

### **Key Concepts:**

* **Component Object**: Represents a commodity or product, including essential details like HS code, quantity, unit, and description. Components are mapped to the requirements for validly creating a Due Diligence Statement in the EU Information System (EU TRACES).

  A component can include:

  * **Supplier traceability** using `supplierBusinessId` (single supplier) or `supplierBusinessIds` (multiple suppliers for mixed-origin).
  * **Plot selection** using `plotIds` (optional). Omit this field to attach all plots of the supplier business.
  * **Upstream DDS traceability** using `ddsReferences` (one or more DDS reference + verification pairs).
  * **Hybrid traceability** by combining `ddsReferences` with supplier/plot information in the same component when your final product includes mixed inputs.
  * **Self-managed plots** by omitting supplierBusinessId(s) and providing plotIds for plots managed under your business account.
  * **Supplementary units** for commodities that need a second quantity alongside net mass:

    * supplementaryUnit (number) — the quantity. Must be positive.
    * supplementaryUnitQualifier (string) — the unit code, e.g. NAR, MTQ, KSD. Required whenever supplementaryUnit is set, and validated against the EUDR code list; an invalid value returns 400 listing the accepted codes.
    * percentageEstimationOrDeviation (number) — expected weight variation of the net mass, in percent. DOMESTIC only, see the warning below.

    For IMPORT and EXPORT the qualifier is determined by the HS code:

    * NAR — 010221, 010229, 4011, 4013, 4104
    * MTQ — 4403, 4406, 4408, 4410, 4411, 4412, 4413
    * KSD — 4701, 4702, 4703, 4704, 4705

    Matching is on the first four digits, except 010221 and 010229, which match in full. TRACES rejects submissions for these HS codes when the supplementary unit is missing.

    ⚠️ Only send percentageEstimationOrDeviation on DOMESTIC transactions. The API accepts it on IMPORT and EXPORT, but TRACES rejects the submission and the transaction ends in ERROR
  * A transaction in TO\_SUBMIT can't be edited and the field can't be cleared once set, so check this before submitting.<br>
* `CustomData`: Metadata related to the transaction. This flexible structure allows users to store relevant information, provided it follows these rules:
  * Maximum of **50 keys**
  * Maximum key length of **255 characters**
  * Maximum string value length of **255 characters**
  * Values must be either **strings, numbers, or booleans**
  * Keys cannot contain the substrings **proto**, **constructor**, or **prototype**
* `supplierBusinessId` / `supplierBusinessIds`
  * `supplierBusinessId` is a unique identifier representing a single supplier business in TradeAware.
  * `supplierBusinessIds` is a list of supplier business IDs used when a single component includes inputs from multiple suppliers (mixed-origin).
* `ddsReferences`: Links a transaction component to one or more Due Diligence Statements (DDS), ensuring compliance and traceability. Each DDS in the array includes:
  * `id`: Unique identifier for the DDS.
  * `verificationNumber`: Code validating the DDS’s authenticity.
  * Validation Rules:
    * When a DDS reference is included in a transaction, the system will verify both the DDS ID and the verificationNumber before submission.
    * If the TRACES API is unavailable or returns an unknown error, new transactions referencing DDS numbers will be rejected with a recommendation to message.
  * ⚠️ Regulatory note (Re-Import / Hybrid): The EU is discussing simplifications to EUDR processes, including how upstream DDS references may be reused. If these changes are implemented, some re-import/hybrid workflows may become less relevant. TradeAware will align with official guidance and this guide will be updated accordingly.
* **Legal Entity (`legalEntityId`)**\
  TRACES requires the exact legal entity responsible for a transaction so the correct name, address and EORI/VAT appear on the DDS. Use `legalEntityId` to select that specific legal entity for a transaction.

  `businessId` vs `legalEntityId`

  * `businessId` → your TradeAware account.
  * `legalEntityId` → a registered legal entity (name, address, EORI/VAT) that can submit to TRACES.\
    A single account can have multiple legal entities (e.g., DE GmbH, IT S.p.A.). Each transaction must specify one legal entity (the DDS primary actor) to ensure the correct EORI/VAT and address are used.

### **Transaction Statuses**

Transactions progress through various statuses during their lifecycle, from creation to final processing in the EU Information System (EU TRACES) as a Due Diligence Statement (DDS). Below is an overview of each status:

* **DRAFT:** The transaction is in draft mode, still being prepared and not yet submitted for processing. It remains editable by the user.
* **TO\_SUBMIT:** The transaction is pending submission to the EU TRACES. At this stage, all necessary data should be finalized.
* **PROCESSING / SUBMITTED:** The transaction has been submitted to EU TRACES and is waiting for validation. This does not guarantee that a DDS reference number or verification number has been assigned. Wait at least 30 minutes after submitting before polling for status; completion can take a few hours or, in some cases, longer, depending on EU TRACES' response times.
* **AVAILABLE:** The transaction has been accepted by EU TRACES and now has a reference and verification number.
* **ERROR / REJECTED:** The transaction was rejected by TRACES or could not be processed successfully.
* **WITHDRAWN:** The transaction was withdrawn from EU TRACES and is no longer active. No DDS reference or verification number will be assigned to a withdrawn transaction.
* **DEPRECATED**: A Trade transaction retired when the TRADE activity type was removed. It remains readable through GET /transactions and GET /transactions/{id}, but accepts no further updates or submission — PATCH /transactions/{id} returns 409 Conflict.

> DDS reference/verification numbers are returned once the transaction is **AVAILABLE**.

### Operators and downstream roles

Operators are typically the first to place a product on the EU market. Their transactions focus on direct traceability to immediate suppliers (supplierBusinessId / supplierBusinessIds) and plot-level geolocation.

Downstream roles that move products already on the EU market no longer file their own DDS. They keep and pass on the DDS references received from their suppliers. Where a downstream step does require a new statement — for example processing that changes the HS code — use DOMESTIC with ddsReferences.

💡 Note: While these are the most common patterns, TradeAware also supports advanced workflows where a component needs both upstream DDS references and supplier plot traceability (hybrid / re-import), and workflows where plots are managed centrally under one account (self-managed model).

### DDS Reference Validation in Transactions API

When referencing a previously submitted Due Diligence Statement (DDS), the API checks that the reference and verification number resolve to a DDS in TRACES before the transaction can be submitted.

Keep your 📘 note underneath unchanged.

Error Handling:\
If the provided DDS reference is invalid or does not match, the API will return:

```json
{
  "message": "One or more DDS references are not valid. Invalid DDS references: {dds_id}",
  "error": "Bad Request",
  "statusCode": 400
}
```

If the TRACES system is unavailable, new transactions using DDS references will be rejected with an instruction to retry later.

📘 The pre-submission check confirms the referenced DDS exists. It no longer confirms that it is still valid — the new EU API does not return a status for a DDS looked up by reference and verification number. A reference that exists but has since been withdrawn or superseded will pass this check and be rejected by TRACES at submission, leaving the transaction in ERROR.

***

### **Use Case 1:** Transaction Management for Operators

Operators need a reliable way to submit transactions that either place goods on the EU market for the first time (Import), export goods out of the EU (Export), or document processing of EU goods (Domestic). They must provide the correct inputs—supplier information, upstream DDS references, or a combination—depending on the workflow.

The API enables operators to create transactions tied to the correct compliance data for their activity type:

* **Import:** Typically requires supplier info + geolocation (plots). Mixed-origin is supported using multiple supplier IDs.
* **Export:** Typically requires upstream DDS references; hybrid workflows are supported where needed.
* **Domestic:** Typically requires upstream DDS references; hybrid workflows are supported where needed.

**Create a New Transaction as an Operator**:

* Description: This is for the entity that is the first to import goods into the EU. Operators are responsible for ensuring that products meet EUDR compliance at the initial point of entry into the EU market.
* Key Requirements:
  * `supplierBusinessId` (or `supplierBusinessIds`) s used to link the transaction component to one or more suppliers.
  * `plotIds` can be used to select specific plots; omit plotIds to attach all supplier plots.
  * `ddsReferences` may be used only when your workflow requires hybrid traceability.

**Steps to Implement:**

1. **Retrieve a list of suppliers:**
   * **Endpoint:** `GET /business-connections/suppliers` to fetch supplier details.
   * **Important:** When linking a transaction to a supplier, you can use any of the following identifiers: EORI, VAT number, email, or the `customData` field if none of the other identifiers are sufficient. We recommend prioritizing EORI or VAT for better traceability and compliance alignment.
   * Example Request:

     ```
     curl -X GET https://api.tradeaware.live-eo.com/business-connections/suppliers \
     -H "Authorization: Bearer <token>"
     ```
   * This returns a list of all the *business connections* that have you as `sourceBusiness` with the data of your suppliers in `targetBusiness` (for each item in the list). Check what `sourceBusiness` and `targetBusiness` mean in our [API reference for business connections](https://docs.live-eo.com/tradeaware/using-the-tradeaware-api/api-reference/business-connections)
     * Your `{businessId}` can be found in the `sourceBusiness` field under `id`.
     * Your supplier's unique identifier (`id`) is located in the `targetBusiness` field.
2. **Create a transaction with supplier-linked components:**

   * **Endpoint:** `POST /transactions`
   * Example Request:

     ```shellscript
     curl -X POST https://api.tradeaware.live-eo.com/businesses/{businessId}/transactions \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -d '{
       "activityType": "IMPORT",
       "countryOfActivity": "DE",
       "legalEntityId": "123e4567-e89b-12d3-a456-426614174000",
       "components": [
         {
           "hsn": "382311",
           "quantity": 100,
           "unit": "KGM",
           "description": "Fuel wood",
           "supplierBusinessId": "589df451-a064-48e6-a715-1315a3f6180a",
           "dateOfProduction": "2023-01-01T00:00:00.000Z"
         }
       ]
     }'
     ```

   📘 **Note**: `legalEntityId` is **optional** when creating a transaction.
3. **Create a transaction for mixed-origin inputs (multiple suppliers on one component):**

   Use `supplierBusinessIds` when one component includes inputs from multiple suppliers.

   Example Request:

   ```bash
   curl -X POST https://api.tradeaware.live-eo.com/transactions \
   -H "Authorization: Bearer <token>" \
   -H "Content-Type: application/json" \
   -d '{
     "activityType": "IMPORT",
     "countryOfActivity": "DE",
     "components": [
       {
         "hsn": "1201",
         "quantity": 123.45,
         "unit": "KGM",
         "description": "Soybean",
         "supplierBusinessIds": [
           "02c36247-1aad-41ba-aa49-f114ca4c263f",
           "1f7e2c11-9d0a-4b65-9df9-1d5d6a3b1111"
         ],
         "plotIds": [
           "a78c1a68-d326-4217-a131-893f3c47a064",
           "e8d2e3e6-2c7c-4c4e-98a9-3e3f4e2c1a68"
         ]
       }
     ],
     "status": "DRAFT"
   }'
   ```
4. **Assign Specific Plots to Components via API**

   When creating or updating a component, you can optionally associate it with specific geolocation plots using the plotIds field.

   * If you do not wish to assign any plots, omit the plotIds field entirely.

   * Passing an empty array (`plotIds: []`) is not supported and will result in a validation error.

   1. **Retrieve available plots**\
      Endpoint: `GET /businesses/{businessId}/plots`\
      Returns a list of plots (each with a unique id) you can later pass in the plotIds array.

      📘 Tip: Use filters such as `filter.riskAssessmentStatus=$eq:EUDR_Non_Compliant` to identify and review non-compliant plots before selection. TradeAware will not automatically exclude them—you decide what to include.
   2. **Add components with specific plots**\
      Endpoint: `POST /transactions/{transaction_id}/components`

      Example Request:

      ```bash
      curl -X POST "https://api.tradeaware.live-eo.com/transactions/{transaction_id}/components" \
      -H "Authorization: Bearer <token>" \
      -H "Content-Type: application/json" \
      -d '{
        "hsn": "1201",
        "quantity": 123.45,
        "unit": "KGM",
        "description": "Soybean",
        "namePairs": [
          { "commonName": "soybean", "scientificName": "Glycine max" }
        ],
        "dateOfProduction": "2021-01-01T00:00:00.000Z",
        "endDateOfProduction": "2022-01-01T00:00:00.000Z",
        "supplierBusinessId": "02c36247-1ad8-41ba-ad49-f11ac44c263f",
        "plotIds": [
          "a78c1a68-d326-4217-a131-893f3c47a064",
          "e8d2e3e6-2c7c-4c4e-98a9-3e3f4e2c1a68"
        ]
      }'
      ```

      📘 Note: Plot selection is always user-driven. TradeAware does not automatically filter or restrict plot inclusion. This flexibility allows you to align selected plots with shipment documentation, harvest batches, or internal sourcing policies.
   3. **Important Validation Rule:**\
      Sending `plotIds: []` (an empty array) is not supported and will return an error:

      ```json
      [
        {
          "property": "plotIds",
          "constraints": {
            "arrayMinSize": "At least one plot must be provided."
          }
        }
      ]
      ```

      1.
5. **List all transactions:**
   * Endpoin&#x74;**:** `GET /transactions`
   * Example Request:

     ```
     curl -X GET https://api.tradeaware.live-eo.com/transactions?includes=components \
     -H "Authorization: Bearer <token>"
     ```
6. **Update an existing order:**
   * Endpoin&#x74;**:** `PATCH /transactions/{transaction_id}`
   * Example Request:
   * <pre><code><strong>curl -X PATCH https://api.tradeaware.live-eo.com/transactions/{transaction_id} \
     </strong>-H "Authorization: Bearer &#x3C;token>" \
     -H "Content-Type: application/json" \
     -d '{
       "customData": {
         "updatedField": "Updated Value"
       }
     }'
     </code></pre>

***

### **Use Case 2: Managing Composite Products**

**Business Case:**

Managing products composed of multiple components while ensuring compliance requires a structured approach to track each material’s origin and DDS references.

**Solution:**

Use the Transactions API to associate multiple components with a transaction. Each component represents a separate HS code line.

💡 Note: Composite products (multiple component rows) are different from mixed-origin components (one component row with multiple suppliers). Use supplierBusinessIds for mixed-origin.

**Steps to Implement:**

1. **Create a composite product with multiple components:**
   * Endpoin&#x74;**:** `POST /transactions`
   * Example Request:

     ```shellscript
     curl -X POST https://api.tradeaware.live-eo.com/transactions \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -d '{
       "activityType": "DOMESTIC",
       "countryOfActivity": "DE",
       "legalEntityId": "123e4567-e89b-12d3-a456-426614174000",
       "components": [
         {
           "hsn": "4015",
           "quantity": 100,
           "unit": "KGM",
           "description": "Articles of apparel and clothing accessories (including gloves, mittens and mitts), for all purposes, of vulcanised rubber other than hard rubber",
           "ddsReferences": [
             { "id": "25DE8TQS813235", "verificationNumber": "ZYKKDTFT" }
           ]
         },
         {
           "hsn": "4016",
           "quantity": 200,
           "unit": "KGM",
           "description": "Other articles of vulcanised rubber other than hard rubber",
           "ddsReferences": [
             { "id": "25DE8TQS813236", "verificationNumber": "ZYKKDTFT" }
           ]
         }
       ]
     }'
     ```
2. **Add a component to a transaction:**
   * Endpoin&#x74;**:** `POST /transactions/{id}/components`
   * Example Request:

     ```shellscript
     curl -X POST https://api.tradeaware.live-eo.com/transactions/{id}/components \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -d '{
       "hsn": "4015",
       "quantity": 200.5,
       "unit": "KGM",
       "description": "Rubber gloves",
       "namePairs": [
         { "commonName": "rubber gloves", "scientificName": "Natural vulcanised rubber" }
       ],
       "dateOfProduction": "2023-01-01T00:00:00.000Z",
       "endDateOfProduction": "2023-12-31T00:00:00.000Z",
       "supplierBusinessId": "589df451-a064-48e6-a715-1315a3f6180a"
     }'
     ```
3. **Update a component:**
   * Endpoin&#x74;**:** `PATCH /components/{id}`
   * Example Request:

     ```shellscript
     curl -X PATCH https://api.tradeaware.live-eo.com/components/{id} \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -d '{
       "quantity": 125.45,
       "unit": "KGM"
     }'
     ```

***

### **Use Case 3: Submitting Transactions to TRACES**

**Business Case:**

Submitting a transaction to the EU Information System (TRACES) is required to obtain a valid Due Diligence Statement (DDS). This step must include correct company (Legal Entity) details and passes through asynchronous validation in TRACES.

#### Prerequisites

* A Legal Entity is associated with the transaction at submission time. Link it via `legalEntityId` (on create or with `PATCH /transactions/{id}`) or provide a full `legalEntity` object in the submit request. If you set `legalEntityId`, the API resolves the full Legal Entity for you—no need to resend it on submit.
  * If `legalEntityId` is not provided, TradeAware will auto-select the oldest Legal Entity on your account at submit time.
* Required identifiers live on the Legal Entity used for submission: EORI for Import/Export; VAT acceptable for Domestic.
* Supplier plots for the component commodity exist. If you send `plotIds`, they must reference valid plots for that supplier (or permitted upstream).

**Solution:**

Use the `submit` endpoint to update a transaction’s status to `TO_SUBMIT`, signaling its readiness for TRACES submission.

**Steps to Implement:**

1. **Find (or create) your Legal Entity ID** (if you prefer the `legalEntityId` path)

   List existing Legal Entities

   ```shellscript
   curl -X GET "https://api.tradeaware.live-eo.com/legal-entities" \
   -H "Authorization: Bearer <token>"
   ```

   Create a Legal Entity (if none exists yet)

   ```shellscript
   curl -X POST "https://api.tradeaware.live-eo.com/legal-entities" \
   -H "Authorization: Bearer <token>" \
   -H "Content-Type: application/json" \
   -d '{
   "name": "Example Palm Oil Trader",
   "email": "user@example.com",
   "addressCity": "West Papua",
   "addressCountryCode": "ID",
   "addressLine1": "Salawati 123",
   "addressLine2": "2nd floor",
   "addressPostcode": "12345",
   "eori": "DE123456789", // EORI for Import/Export
   "vat": "1234567890" // VAT acceptable for Domestic
   }'
   ```

   📘 **Note**: Copy the `id` from the response and use it as `legalEntityId` on **create** or via `PATCH /transactions/{id}` before submitting.
2. **Submit a transaction:**
   * Endpoint: `PUT /transactions/{id}/submit`
   * Example Request:

     ```shellscript
     curl -X PUT https://api.tradeaware.live-eo.com/transactions/{id}/submit \
     -H "Authorization: Bearer <token>"
     ```
   * Example Response:

     <pre class="language-shellscript"><code class="lang-shellscript">{
       "id": "fb6c9222-3204-4612-8ed7-8db516c6c715",
       "status": "TO_SUBMIT",
       "activityType": "EXPORT",
       "countryOfActivity": "IT",
       "customId": "DEC-24-238620",
       "components": [
         {
           "commodity": "soya",
           "ddsReference": {
             "id": "24DKYIGLPU3439",
             "verificationNumber": "4NAB3QYM"
           }
         }
       ]
     <strong>// Note: Additional parameters may be returned in the response but are omitted here for brevity.
     </strong>}
     </code></pre>
3. **Receiving a DDS Reference and Verification Number**

After a transaction is successfully submitted to TRACES, the system continuously checks for the assigned DDS reference and verification number. Since TRACES assigns these asynchronously, TradeAware automatically retrieves and updates them.

* Endpoint: `GET /transactions/{id}`
* Example Request:

  <pre class="language-shellscript"><code class="lang-shellscript"><strong>curl -X GET https://api.tradeaware.live-eo.com/transactions/fb6c9222-3204-4612-8ed7-8db516c6c715 \
  </strong>-H "Authorization: Bearer &#x3C;token>"
  </code></pre>

DDS reference and verification numbers are returned once the transaction is **AVAILABLE**.

***

### **Use Case 4: Linking Transactional Data to Compliance Workflows (e.g., Batches, Shipments)**

**Business Case:**

Businesses need to link transactional data, such as batches, shipments, Purchase Orders etc. to compliance workflows to create a robust audit trail and maintain regulatory compliance. Without this linkage, inefficiencies and compliance risks can arise.

**Solution:**

Leverage the `customData` field in the Transactions API to associate SOs with POs for seamless traceability.

**Create a Batch linked to a purchase order:**

* Endpoint: `POST /transactions`
* Example Request:

  ```shellscript
  curl -X POST https://api.tradeaware.live-eo.com/businesses/{businessId}/transactions \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "activityType": "DOMESTIC",
    "countryOfActivity": "US",
    "components": [],
    "customData": {
      "transactionType": "Batch",
      "linkedOrders": "PO001",
      "salesRegion": "North America"
    }
  }'
  ```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.live-eo.com/tradeaware/using-the-tradeaware-api/manage-your-transactions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
