# 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.

### :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 systemRemember to stay on Acceptance while testing and switch to PRODUCTION only when 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>TRADE</code></td><td>Reselling goods already on the EU market, no change</td><td>Upstream DDS references (ddsReferences) are typical</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`

📘 Tip: If you need to represent a single final product that has multiple upstream sources, see the “Mixed-origin / Hybrid / Self-managed” patterns below.

### List of Use Cases

1. Transaction Management for Operators (Activity: Import, Export, Domestic)
2. Transaction Management for Traders (Activity: Trade)
3. Managing Composite Products
4. Submitting Transactions to TRACES
5. 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.
* `CustomData`: Metadata related to the transaction. This flexible structure allows users to store relevant information, provided it follows these rules:w
  * 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. This process might take up to 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.

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

### **Transaction Management accommodate for both Operators and Traders needs**

Operators and traders play distinct roles in the compliance chain under the EU Information System (EU TRACES).

* Operators are typically the first person to make a product available on the EU market. Their transactions usually focus on direct traceability to immediate suppliers (supplierBusinessId / supplierBusinessIds) and plot-level geolocation.
* Traders are those who subsequently move products already available in the EU market. Their transactions typically emphasize linking products to existing DDS references (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 performs validation checks to ensure the provided DDS ID and verificationNumber are correct.

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.

***

### **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:** Transaction Management for Traders

**Business Case:**

Traders must comply with regulatory requirements by ensuring traceability of DDS references for each transaction. Forwarding upstream DDS references can be complex when dealing with multiple components.

**Solution:**

Traders need to submit transactions to forward or reuse existing DDS references when reselling goods within the EU without transformation. In advanced workflows, a component may also include supplier plot traceability (hybrid) where required.

**Create a New Transaction as a Trader**:

* Description: This is for entities that make relevant products available on the market. Traders are involved in the subsequent movement of goods and must link products to upstream DDS references.
* Key Requirements:
  * `supplierBusinessId(s)` are typically not required when referencing upstream DDS, but may be included for hybrid workflows where needed.
  * `ddsReferences` should be provided for traceability.

**Steps to Implement:**

1. **Create a transaction with DDS references:**

* Endpoin&#x74;**:** `POST /transactions`
* Example Request:

```shellscript
{
  "activityType": "TRADE",
  "countryOfActivity": "DE",
  "legalEntityId": "123e4567-e89b-12d3-a456-426614174000",
  "components": [
    {
      "ddsReferences": [
        {
          "id": "a12b3456-c789-41de-b012-3456789abcde",
          "verificationNumber": "DE-2024-XYZ-000123"
        }
      ],
      "unit": "KGM",
      "quantity": 1200,
      "hsn": "18069000",
      "description": "Cocoa-based preparation, retail packs"
    }
  ]
}

```

**Note:** The system will validate the provided **DDS referenceNumber** and **verificationNumber** before accepting the transaction.

2. **Retrieve Information about an existing DDS from the EU Information System**

Optiona&#x6C;**:** This action allows you to retrieve and check the data in a reference DDS before making use of it.

* Endpoin&#x74;**:** `GET /dds/fetch-dds-data`
* Example Request:

```shellscript
curl -X 'GET' \
'https://api.tradeaware.live-eo.com/dds/fetch-dds-data?verificationNumber=<verificationNumber>&referenceNumber=<referenceNumber>' \
-H 'accept: */*' \
-H 'Authorization: Bearer <token>'
```

***

### **Use Case 3: 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": "TRADE",
       "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 4: 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/Trade.
* 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/Trade
   }'
   ```

   📘 **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 5: 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": "SALE",
    "countryOfActivity": "US",
    "components": [],
    "customData": {
      "transactionType": "Batch",
      "linkedOrders": "PO001",
      "salesRegion": "North America"
    }
  }'
  ```


---

# Agent Instructions: 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:

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

The question should be specific, self-contained, and written in natural language.
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.
