> For the complete documentation index, see [llms.txt](https://developer.esw.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.esw.com/package-api/resources/postman-collection/manifest-and-shipment.md). # Manifest & Shipment ### What This Collection Does This Postman collection covers the **Manifest & Shipment workflow** — the sequence of API calls that creates a package, confirms it in the system, and assigns it to an outbound air freight manifest with flight and pallet information. {% file src="/files/Jri32LsZRFTrEadVffa6" %} {% hint style="info" %} You need [**Postman**](https://postman.com/) to use this collection {% endhint %} It uses the **ESW Package API v4** and covers three steps ```ruby Create Package → Retrieve Package → Update Manifest ``` The workflow connects two distinct operations: package creation (which generates shipping labels and documentation) and manifest management (which links the physical package to a specific flight and pallet for air freight tracking) *** ### Import the Collection {% stepper %} {% step %} #### Open Postman {% endstep %} {% step %} #### Click the three dots :ellipsis: Click **Import** from the three dots in the top left corner {% endstep %} {% step %} #### Upload file :file-code: Drag and drop `ESW_Manifest_Shipment.postman_collection.json` into the import window, or click **Upload Files** and select it {% endstep %} {% step %} #### Confirm Click **Import** to confirm {% hint style="info" %} The collection will appear in your left sidebar under **Collections** as: {% code expandable="true" %} ```ruby ESW Package API — Manifest & Shipment ``` {% endcode %} Expand it to see all ten requests listed in step order. {% endhint %} {% endstep %} {% endstepper %} *** ### Set Up Variables The collection uses variables. Set them once and every request picks them up automatically. **To set them:** 1. Click the collection name in the sidebar 2. Click the **Variables** tab at the top of the right panel
Fill in the column
VariableWhat to enterExampleAuto-managed?
baseUrlThe API base URLhttps://logistics-package-api.sandbox.eshopworld.comNo
tokenYour Bearer JWTeyJhbGci...No
brandCodeYour 3-letter brand identifierACMNo
orderReferenceLeave as default — auto-generated by Step 1ORD-2024-00001Yes — Step 1 pre-request
packageReferenceLeave as default — auto-generated by Step 1PKG-2024-00001Yes — Step 1 pre-request
eShopPackageReferenceLeave blank — auto-populated from Step 1 and Step 2(empty)Yes — Step 1 and Step 2 test scripts
manifestNumberThe manifest number for the outbound flightMAN-2024-00001No
Click **Save** (`Cmd + S` on Mac / `Ctrl + S` on Windows) after filling in your values. #### How auto-managed variables work **`orderReference` and `packageReference`** — Before Step 1 runs, the pre-request script checks whether these are still set to the default placeholder values (`ORD-2024-00001` / `PKG-2024-00001`). If so, it generates unique values using the current Unix timestamp: ``` orderReference → ORD-1714556400123 packageReference → PKG-1714556400123 ``` To use your own references instead of auto-generated ones, simply update the Current Value in the Variables tab to your desired values before running Step 1. The script only generates new ones when the default values are detected. **`eShopPackageReference`** — This is the **integer** reference that ESW assigns internally when a package is created. It is different from your `packageReference` string. It is required in the Step 3 manifest payload. The Step 1 test script saves it automatically if returned in the Create response. The Step 2 test script saves it as a fallback if Step 1 didn't return it. You should never need to set this manually. *** ### Authentication The collection uses **Bearer Token** authentication at the collection level. Every request automatically sends: ``` Authorization: Bearer {{token}} ``` **To verify it's configured:** 1. Click the collection name in the sidebar 2. Click the **Authorization** tab 3. **Auth Type** should show **Bearer Token** 4. **Token** should show `{{token}}` Individual requests inherit this setting — when you open any request's **Authorization** tab, it will show **Inherit auth from parent**. **Refreshing an expired token:** If any request returns `401 Unauthorized`, your JWT has expired: 1. Click the collection name 2. Click **Variables** 3. Update the **Current Value** of `token` 4. Click **Save** All three requests will use the refreshed token immediately. *** ### Manifest & Shipment Workflow {% code expandable="true" %} ```ruby ┌──────────────────────────────────────────────────────────────────────┐ │ │ │ Step 1 — Create Package POST │ │ Submit package with line items, consignee, │ │ weight, dimensions, carrier, and pricing → 200 OK │ │ │ │ Response includes: │ │ · outcome (label created, on hold, error) │ │ · eShopPackageReference (integer) ← saved to variable │ │ · shippingDocumentation (label URLs) │ │ │ │ │ ▼ │ │ Step 2 — Retrieve Package GET │ │ Confirm package exists, verify shippingStatus │ │ is Pending, capture eShopPackageReference → 200 OK │ │ │ │ Key checks: │ │ · shippingStatus must be "Pending" │ │ · holdReleaseStatus must be "Release" │ │ · eShopPackageReference saved for Step 3 │ │ │ │ │ ▼ │ │ Step 3 — Update Manifest POST │ │ Link the package to its outbound flight │ │ via pallet assignment → 200 OK │ │ │ │ Payload uses: │ │ · {{eShopPackageReference}} (integer from Step 2) │ │ · Flight details (carrier code, number, ETD, ETA) │ │ · Pallet reference and IATA airport codes │ │ │ └──────────────────────────────────────────────────────────────────────┘ ``` {% endcode %} #### Sync vs async All three steps in this collection are **synchronous** — the response reflects the outcome immediately. There is no polling required between steps, unlike the Order Transaction API. However: * A package can only be manifested if its `shippingStatus` is `Pending`. Step 2 checks this explicitly. * A package on `Hold` cannot be manifested. Step 2 warns if this is the case. #### The two package references | Reference | Type | Set by | Used in | | ----------------------- | ------- | ------------------ | ------------------------------- | | `packageReference` | String | You (the retailer) | Step 1 body, Step 2 query param | | `eShopPackageReference` | Integer | ESW | Step 3 manifest pallets | *** ### Step 1 — Create Package **Method:** `POST` **URL:** `{{baseUrl}}/api/v4/Package` #### What it does Creates a new package in the ESW system. This is a **synchronous** operation — the response returns immediately with the full package record, the label outcome, and shipping documentation URLs if `shippingDocumentationRequested` was set to `true`. #### The request body Click **Body** → confirm **raw** and **JSON** are selected. The body is pre-filled with two sample line items. Replace them with the actual package and product data before sending: {% code expandable="true" %} ```json { "brandCode": "{{brandCode}}", "orderReference": "{{orderReference}}", "packageReference": "{{packageReference}}", "orderType": "CHECKOUT", "weight": { "weight": 1.85, "weightUnit": "KG" }, "shippingStatus": "Pending", "shippingDocumentationRequested": true, "returnDocumentationRequested": false, "isBackOrder": false, "dangerousGoods": false, "serviceLevel": "Standard", "distributionCentre": "IEDUB", "carrierId": 12, "carrierReference": "CARR-REF-2024-00001", "goodsDescription": "Clothing and Footwear", "dimensions": { ... }, "consignee": { ... }, "shippingInfo": { ... }, "insuranceAmount": { ... }, "packageItems": [ ... ], "metadata": { ... } } ``` {% endcode %} #### Pre-request script — auto-generating references Before sending, Postman runs a script that auto-generates `orderReference` and `packageReference` using the current timestamp if they are still at their default placeholder values. The Console will show: ``` Generated orderReference: ORD-1714556400123 Generated packageReference: PKG-1714556400123 ``` To use specific references, update the variable **Current Values** before running Step 1. The script only triggers when defaults are detected. #### Expected response — 200 OK Package creation always returns `200 OK` regardless of the label outcome. The `outcome` field tells you what actually happened: | Outcome | Meaning | Action | | ------------------------------ | ------------------------------------------------------- | ----------------------------------------------------------- | | `PackageAndLabelCreated` | Package and shipping label both created | Check `shippingDocumentation` for label URLs | | `PackageCreated` | Package created, no label (documentation not requested) | Proceed normally | | `PackageCreatedAndLabelOnHold` | Package created, label held pending review | Check `holdReleaseStatus` — resolve hold before manifesting | | `PackageCreatedAndLabelError` | Package created, label generation failed | Retry label generation separately; package is still valid | | `PackageNotCreated` | Package was not created | Check the `statusMessage` for the reason | The test script checks the `outcome` field and logs a warning for label issues. It also saves `eShopPackageReference` to the collection variable automatically if it is present in the response. #### Saved example responses Click the **Examples** dropdown (the arrow next to **Send**) to see: | Example | When it applies | | ------------------------------------------ | --------------------------------------------- | | `200 OK — Package and Label Created` | Full success — package and label both created | | `200 OK — Package Created (Label on Hold)` | Package created but label is held | | `409 Conflict — Package Already Exists` | A package with this reference already exists | | `400 Bad Request — Validation Failure` | A required field is missing or invalid | #### Test results | Test | Passes when | | --------------------------------------------- | ------------------------------------ | | `Package created (200)` | Response status is 200 | | `Response has outcome field` | Body contains an `outcome` key | | `Package was created (not PackageNotCreated)` | `outcome` is not `PackageNotCreated` | #### Console output ``` Generated orderReference: ORD-1714556400123 Generated packageReference: PKG-1714556400123 Outcome: PackageAndLabelCreated eShopPackageReference: 987654 Carrier: DHL Shipping status: Pending Hold/Release status: Release ✓ Label created. Shipping docs: 1 ShippingLabel: https://docs.esw.com/labels/PKG-1714556400123.pdf ✓ eShopPackageReference saved for Step 3: 987654 ``` *** ### Step 2 — Retrieve Package **Method:** `GET` **URL:** `{{baseUrl}}/api/v4/Package?BrandCode={{brandCode}}&PackageReference={{packageReference}}` #### What it does Fetches the full package record using the brand code and package reference. This step serves two purposes: 1. **Confirms** the package was created and is in the expected state before proceeding to the manifest 2. **Captures** the `eShopPackageReference` integer as a fallback if Step 1 didn't return it It also performs two safety checks critical to the manifest workflow — verifying `shippingStatus` is `Pending` and warning if the package is on `Hold`. #### Query parameters The **Params** tab shows three parameters: | Parameter | Status | Description | | ------------------ | --------------- | ------------------------------------------------------------------------------------------- | | `BrandCode` | Active | Required. Pre-filled from `{{brandCode}}` | | `PackageReference` | Active | Required. Pre-filled from `{{packageReference}}` | | `OrderReference` | Disabled (grey) | Optional. Click the checkbox to enable if you need to narrow the lookup to a specific order | Do not change the active parameters — they are resolved from your collection variables automatically. #### No body required This is a GET request. The **Body** tab will show **none**. Everything is passed via query parameters. #### Expected response — 200 OK The response returns the full package record. Key fields to check: | Field | What to look for | | ------------------------ | ----------------------------------------------------------------------- | | `eShopPackageReference` | An integer (e.g. `987654`). This gets saved to the variable for Step 3. | | `shippingStatus` | Must be `Pending` to proceed. `Complete` packages cannot be manifested. | | `holdReleaseStatus` | Must be `Release`. `Hold` packages cannot be manifested. | | `trackingUrl` | Carrier tracking link, available after label creation. | | `shippingDocumentation` | Array of label document URLs. | | `parcelCarrierReference` | The carrier's own tracking number assigned to the parcel. | #### Test results | Test | Passes when | | ------------------------------------------------------- | ------------------------------------- | | `Package retrieved (200)` | Response status is 200 | | `Response has eShopPackageReference` | Body contains `eShopPackageReference` | | `Package shippingStatus is Pending (safe for manifest)` | `shippingStatus` equals `Pending` | > The third test — checking `shippingStatus` is `Pending` — will **fail red** if the package has already been marked `Complete`. This is a deliberate guard: attempting to manifest a complete package will be rejected by the API. #### Console output ``` Package reference: PKG-1714556400123 eShopPackageReference: 987654 Shipping status: Pending Hold/Release status: Release Carrier: DHL Carrier reference: CARR-REF-2024-00001 Parcel carrier ref: 1Z999AA10123456784 Tracking URL: https://tracking.dhl.com/track?ref=CARR-REF-2024-00001 Shipping docs: 1 ✓ eShopPackageReference saved: 987654 Safe to proceed with Step 3 — Update Manifest. ``` If the package is in a problematic state: ``` ⚠ Package is already Complete. Manifest update may be rejected. ``` or ``` ⚠ Package is on Hold. Resolve the hold before manifesting. ``` *** ### Step 3 — Update Manifest **Method:** `POST` **URL:** `{{baseUrl}}/api/v4/Manifest` #### What it does Updates the air freight manifest with flight details, carrier information, and pallet assignments. This links the physical package to its outbound flight — essential for air freight tracking and customs documentation. #### The pre-request safety check Before sending, a script checks that `eShopPackageReference` is populated. If it's empty, you'll see a warning in the Console: ``` ⚠ eShopPackageReference is not set. Run Step 2 first so the package reference is saved automatically. Or set it manually in the collection Variables tab. ``` If the reference is set correctly: ``` eShopPackageReference resolved to: 987654 ``` The request will still send either way — but if the variable is empty, the `pallets` array will contain an empty value and the API will return a validation error. #### The request body {% code expandable="true" %} ```json { "manifestNumber": "{{manifestNumber}}", "originAirportCode": "DUB", "destinationAirportCode": "FRA", "carrierId": 12, "groundHandlingAgent": "Swissport", "flight": { "carrierCode": "EI", "flightNumber": "EI526", "estimatedTimeOfDeparture": "2024-05-02T06:30:00Z", "estimatedTimeOfArrival": "2024-05-02T09:45:00Z" }, "pallets": [ { "palletReference": "PAL-2024-001", "eShopPackageReferences": [ {{eShopPackageReference}} ] } ] } ``` {% endcode %} **Before sending, update:** * `originAirportCode` and `destinationAirportCode` — use IATA 3-letter airport codes (e.g. `DUB`, `LHR`, `JFK`, `FRA`, `AMS`) * `carrierId` — the ESW integer carrier identifier (must match the `carrierId` used in Step 1) * `groundHandlingAgent` — name of the ground handler at the origin airport * `flight.carrierCode` — 2-letter IATA airline code (e.g. `EI` = Aer Lingus, `LH` = Lufthansa, `AA` = American) * `flight.flightNumber` — full flight number including carrier code (e.g. `EI526`, `LH1234`) * `flight.estimatedTimeOfDeparture` and `flight.estimatedTimeOfArrival` — ISO 8601 UTC datetimes * `pallets[0].palletReference` — your reference for the physical pallet **Do not change `{{eShopPackageReference}}`** in the body — it is resolved automatically from the variable set by Step 2. #### Assigning multiple packages to one pallet Add additional `eShopPackageReference` integers to the array, separated by commas: ```json "eShopPackageReferences": [987654, 987655, 987656] ``` Each integer corresponds to a different package that was created in Step 1. Run Steps 1 and 2 for each package first to collect all their `eShopPackageReference` values, then build the manifest payload manually. #### Assigning packages across multiple pallets Add additional objects to the `pallets` array: {% code expandable="true" %} ```json "pallets": [ { "palletReference": "PAL-2024-001", "eShopPackageReferences": [987654, 987655] }, { "palletReference": "PAL-2024-002", "eShopPackageReferences": [987656, 987657] } ] ``` {% endcode %} #### Expected responses | Response | Meaning | What to do | | ------------------ | ------------------------------------------------------- | ----------------------------------------------------------- | | `200 OK` | Manifest updated successfully | Workflow complete | | `204 No Content` | Request accepted but no matching manifest content found | Verify `manifestNumber` is correct and exists in the system | | `400 Bad Request` | Validation failure | Check error body for the specific field | | `404 Not Found` | Manifest not found | Verify `manifestNumber` in the Variables tab | | `401 Unauthorized` | Token expired | Refresh token and retry | #### Saved example responses Click **Examples** to see: | Example | Response code | | -------------------------------------- | ------------- | | `200 OK — Manifest Updated` | 200 | | `204 No Content — Nothing Found` | 204 | | `404 Not Found — Manifest Not Found` | 404 | | `400 Bad Request — Validation Failure` | 400 | #### Test results | Test | Passes when | | --------------------------------------------- | ----------------------------- | | `Manifest updated or no content (200 or 204)` | Response status is 200 or 204 | #### Console output on success ``` ✓ Manifest updated successfully. === Manifest & Shipment Workflow Complete === Brand: ACM Order reference: ORD-1714556400123 Package reference: PKG-1714556400123 eShop pkg reference: 987654 Manifest number: MAN-2024-00001 Steps: Create Package → Retrieve Package → Update Manifest ``` On 204: ``` ⚠ 204 No Content — manifest content not found. Verify the manifestNumber is correct. ``` *** ### Run Collection The Collection Runner lets you run all three steps automatically in sequence. #### Opening the runner 1. Hover over the collection name in the left sidebar 2. Click the **⋯** (three dots) menu that appears 3. Select **Run** #### Recommended settings | Setting | Value | Why | | ----------------------------------- | -------- | --------------------------------------------------------------------------------------- | | **Iterations** | `1` | One package per run | | **Delay** | `500` ms | Small buffer between steps | | **Persist responses for a session** | ✓ On | Lets you inspect each response after the run | | **Stop run if an error occurs** | ✓ On | Stops if a step fails — prevents Step 3 running without a valid `eShopPackageReference` | | **Keep variable values** | ✓ On | Ensures `eShopPackageReference` set in Step 1/2 carries into Step 3 | Unlike the Order Transaction API, these steps are all synchronous — a `500` ms delay is enough. The API does not require long waits between calls. #### After the run Click any request row in the results to see its response body, test outcomes, and console output. The workflow summary is printed to the console after Step 3. *** ### Reading Test Results and Console Output #### Test Results tab After sending any request, click **Test Results** in the response panel to see pass/fail status. **All tests across the collection:** | Step | Test | Passes when | | ------ | ------------------------------------------------------- | ------------------------------------ | | Step 1 | `Package created (200)` | Status is 200 | | Step 1 | `Response has outcome field` | Body has `outcome` key | | Step 1 | `Package was created (not PackageNotCreated)` | `outcome` ≠ `PackageNotCreated` | | Step 2 | `Package retrieved (200)` | Status is 200 | | Step 2 | `Response has eShopPackageReference` | Body has `eShopPackageReference` key | | Step 2 | `Package shippingStatus is Pending (safe for manifest)` | `shippingStatus` equals `Pending` | | Step 3 | `Manifest updated or no content (200 or 204)` | Status is 200 or 204 | #### Postman Console Open via **View → Postman Console** or `Cmd + Alt + C` (Mac) / `Ctrl + Alt + C` (Windows/Linux). > Open the Console **before** running requests. Postman does not retain output from requests sent before the Console was open. **What the Console shows per step:** | Step | Console output | | ------------------ | ------------------------------------------------------------------------- | | Step 1 pre-request | Auto-generated references if defaults were used | | Step 1 post-send | Label outcome, `eShopPackageReference`, carrier, label URLs | | Step 2 | All package fields, `eShopPackageReference` confirmation, status warnings | | Step 3 pre-request | `eShopPackageReference` value check | | Step 3 post-send | Success confirmation or 204 warning, full workflow summary | *** ### Package Create — Field Reference Replace the sample values in Step 1 with real data for each package. The following tables cover every field in the request body. #### Required fields | Field | Type | Description | Example | | ------------------- | ------ | ------------------------------------------------------ | ------------------ | | `brandCode` | string | ESW's 3-letter brand identifier | `"ACM"` | | `orderReference` | string | Retailer's unique order reference | `"ORD-2024-00001"` | | `packageReference` | string | Retailer's unique package reference — cannot be reused | `"PKG-2024-00001"` | | `orderType` | enum | Type of order | `"CHECKOUT"` | | `weight.weight` | number | Total package weight | `1.85` | | `weight.weightUnit` | enum | Weight unit | `"KG"` | #### Enum values **`orderType`** ``` CHECKOUT Standard eShopWorld checkout order NONCHECKOUT Non-checkout order (requires productDescription and hsCode per item) RETURN Return shipment OFFLINE Order placed outside eShopWorld checkout NONCHECKOUTECOMMERCE E-commerce order not using eShopWorld checkout ``` **`weight.weightUnit`** ``` KG LB ``` **`shippingStatus`** ``` Pending Use for all new packages (default) Complete Package has been fully shipped — cannot be manifested or updated ``` **`serviceLevel`** ``` POST EXP1 EXP2 RussiaExpress Standard Pudo ``` **`dimensions.dimMeasurementUnit`** ``` CM IN ``` #### dimensions object ```json { "dimHeight": "25", "dimLength": "35", "dimWidth": "15", "dimWeight": "1.85", "dimMeasurementUnit": "CM" } ``` All dimension values are strings, not numbers. #### consignee object | Field | Required | Description | | ------------ | -------- | ------------------------------------------------------ | | `firstName` | Yes | Recipient first name | | `lastName` | Yes | Recipient last name | | `address1` | Yes | Address line 1 | | `city` | Yes | City | | `postalCode` | Yes | Postal / zip code | | `country` | Yes | ISO 3166 2-letter country code (e.g. `DE`, `US`, `GB`) | | `email` | Yes | Recipient email address | | `telephone` | Yes | Recipient phone number including country code | | `address2` | No | Address line 2 | | `address3` | No | Address line 3 | | `region` | No | Region, state, or county | | `gender` | No | Gender of recipient | | `unit` | No | Unit number | | `name` | No | Used for Ship to Store — e.g. store name | #### `packageItems` array Each item requires: | Field | Required | Description | | --------------------------- | ------------------------ | --------------------------------------------------------- | | `productCode` | Yes | Retailer's SKU | | `quantity` | Yes | Number of units. Only `> 1` if all items are identical. | | `weight` | Yes | `{ "weight": 0.35, "weightUnit": "KG" }` | | `lineItemId` | No | `LineItemId` from the checkout (integer) | | `productDescription` | No (Yes for NONCHECKOUT) | Plain-language product description | | `productCustomsDescription` | No | Customs-facing description including material composition | | `countryOfOrigin` | No | ISO 3166 2-letter manufacturing country (e.g. `IE`, `CN`) | | `unitPrice` | No | `{ "amount": 89.99, "currency": "EUR" }` | | `hsCode` | No (Yes for NONCHECKOUT) | Harmonized System tariff code | | `fta` | No | `true` if covered under free trade agreement | | `dangerousGoods` | No | `true` if item is hazardous | | `serialNumber` | No | Serial number of the item | | `warrantyId` | No | Warranty ID of the item | #### Optional top-level fields | Field | Description | | ---------------------------------- | -------------------------------------------------------- | | `shippingDocumentationRequested` | `true` to generate and return label URLs in the response | | `returnDocumentationRequested` | `true` to generate a return label | | `isBackOrder` | `true` if this is not the first shipment for the order | | `dangerousGoods` | `true` if the package contains hazardous items | | `dangerousGoodsClassificationCode` | DG classification code | | `dangerousGoodsUNNumber` | DG UN number | | `carrierId` | ESW integer carrier ID | | `carrierReference` | Carrier's own reference for this package | | `distributionCentre` | Origin DC code (e.g. `IEDUB`, `AUCOW`, `HKHKG`, `FRPAR`) | | `hubCode` | Hub processing code (retailer-specific) | | `parentOrderReference` | Original order reference for back-orders | | `goodsDescription` | Package contents description for customs | | `serviceLevel` | Delivery service level | | `palletId` | Pallet identifier | | `shippingInfo` | Shipping cost `{ "amount": 5.99, "currency": "EUR" }` | | `insuranceAmount` | Insured value `{ "amount": 165.96, "currency": "EUR" }` | | `additionalImportInformation` | Certificates and import documentation notes | | `additionalCarrierData` | Five free-text fields for carrier-specific data | | `metadata` | Any custom key-value pass-through data | *** ### Common Scenarios #### "Creating a package and manifesting it on the same flight" Run Steps 1, 2, and 3 in order. Steps 1 and 2 auto-manage the `eShopPackageReference` variable so Step 3 is ready to send without any manual changes. *** #### "Adding multiple packages to the same manifest pallet" Run Steps 1 and 2 for each package separately. After each Step 2, note the `eShopPackageReference` logged in the Console. Then in Step 3, manually add all references to the `eShopPackageReferences` array: ```json "eShopPackageReferences": [987654, 987655, 987656] ``` Only the last Step 2 value will be in `{{eShopPackageReference}}` — the others must be added manually to the body. *** #### "The label came back on hold after Step 1" The `outcome` field will show `PackageCreatedAndLabelOnHold` and `holdReleaseStatus` will be `Hold`. The package exists but the label is held for review. You can still retrieve it in Step 2, but Step 2 will warn that the package is on hold. Resolve the hold through your ESW account team before attempting to manifest. *** #### "Step 2 fails the Pending status test" The `shippingStatus` is `Complete`, meaning the package has already been fully shipped. A complete package cannot be updated or manifested. If this was a mistake, contact your ESW account team. If intentional (you're checking a completed package), the test failing red is expected — it's a safety guard, not an error to fix. *** #### "Using specific order and package references instead of auto-generated ones" Before running Step 1, go to the Variables tab and set the **Current Value** of `orderReference` and `packageReference` to your desired values. The pre-request script only auto-generates when it detects the default placeholder values (`ORD-2024-00001` / `PKG-2024-00001`). *** #### "Running the workflow for a NONCHECKOUT order" Change `orderType` to `NONCHECKOUT` in the Step 1 body. For NONCHECKOUT orders, the following fields become required per `packageItem`: * `productDescription` — plain-language description * `hsCode` — Harmonized System tariff code The API will return `400` or `422` if these are missing for NONCHECKOUT packages. *** ### Troubleshooting **`401 Unauthorized` on any request** Your JWT token has expired. Get a new one, update the `token` variable **Current Value**, and click **Save**. *** **`400 Bad Request` on Step 1** A required field is missing or has an invalid value. The response body `message` field will identify the specific field. Common causes: * `weight` missing entirely — the object `{ "weight": 1.85, "weightUnit": "KG" }` must be present * `orderType` not one of the valid enum values — check capitalization (`CHECKOUT` not `Checkout`) * `consignee.country` not a valid ISO 2-letter code — use `DE` not `Germany` * `packageReference` already used — each package reference must be unique per brand *** **`409 Conflict` on Step 1** A package with this `packageReference` already exists for this brand. Either use a different reference or delete the existing package first. If using auto-generation, check the Console — the generated reference is logged. *** **`404 Not Found` on Step 2** The package doesn't exist yet, or `BrandCode` / `PackageReference` are wrong. Check the active query parameters in the **Params** tab — confirm both are populated with your variable values, not the literal strings `{{brandCode}}` / `{{packageReference}}`. *** **Step 2 test `Package shippingStatus is Pending` fails** The package `shippingStatus` is `Complete`. Complete packages cannot be manifested. If this is unexpected, verify you are looking at the correct package reference. *** **`404 Not Found` on Step 3** The `manifestNumber` doesn't exist in the ESW system. Verify the value in the **Variables** tab. Manifest records are typically pre-created by the ESW platform or carrier integration before packages are assigned to them. *** **`204 No Content` on Step 3** The request was accepted but no matching manifest content was found. This usually means the `manifestNumber` value is correct in format but doesn't match an active manifest. Verify the number with your ESW logistics contact. *** **`eShopPackageReference` is empty in Step 3 body** Step 2 was not run before Step 3, or the variable was not saved. Check the Console — Step 2 logs a confirmation line when the reference is saved. If it's missing, run Step 2 and check the Console output. As a last resort, manually set the `eShopPackageReference` **Current Value** in the Variables tab to the integer returned in the Step 1 or Step 2 response body. *** **`{{eShopPackageReference}}` appears literally in the Step 3 request body** The variable has no value. Open the Variables tab and confirm the **Current Value** of `eShopPackageReference` is set. If it's blank, run Step 2 first or set it manually. Click **Save** after updating. *** **Console shows nothing** The Console must be open before sending a request. Open it via **View → Postman Console** (`Cmd + Alt + C` on Mac / `Ctrl + Alt + C` on Windows/Linux), then re-run the request. --- # 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://developer.esw.com/package-api/resources/postman-collection/manifest-and-shipment.md?ask=&goal= ``` `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.