Qargo API / Task API
The API / Task API from Qargo — 3 operation(s) for api / task.
OpenAPI Specification
openapi: 3.1.0
info:
title: Qargo TMS API / Accounting API / Task API
description: "For support, please contact integrations@qargo.com.\n# Overview\n\n<div style=\"background: linear-gradient(135deg, #1C2C31 0%, #304045 100%); color: white; padding: 20px; border-radius: 10px; margin: 20px 0;\">\n <h2 style=\"color: white; margin-top: 0;\">Tenant API Documentation</h2>\n <p style=\"font-size: 16px; margin-bottom: 0;\">You are currently viewing the <strong>Tenant API Documentation</strong>. This API provides access to tenant-level integrations and operational endpoints.</p>\n</div>\n\n<div style=\"border-left: 4px solid #00E85B; background: #F4FBF7; padding: 14px 18px; border-radius: 6px; margin: 20px 0;\">\n <strong>What's new</strong> — see the <a href=\"/docs/section/changelog\">Changelog</a> for recent additions and changes to the API.\n</div>\n\n<br/>\n\n### Documentation for Other Parties\n\n<div style=\"display: grid; grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)); gap: 20px; margin: 30px 0;\">\n\n<div style=\"border: 2px solid #00E85B; border-radius: 10px; padding: 20px; background: #F4FBF7; transition: transform 0.2s;\">\n <h3 style=\"color: #36BB6B; margin-top: 0;\">Subcontractor API</h3>\n <p>Fleet dispatch and subcontractor-specific endpoints for transportation management.</p>\n <div style=\"text-align: center; margin-top: 15px;\">\n <a href=\"https://api-docs.qargo.com/subcontractor/docs\" style=\"\n display: inline-block;\n background: #00E85B;\n color: white;\n padding: 12px 24px;\n text-decoration: none;\n border-radius: 6px;\n font-weight: bold;\n transition: background 0.3s;\n \">Subcontractor Documentation</a>\n </div>\n</div>\n\n<div style=\"border: 2px solid #6F82FB; border-radius: 10px; padding: 20px; background: #F4FBF7; transition: transform 0.2s;\">\n <h3 style=\"color: #6F82FB; margin-top: 0;\">Customer API</h3>\n <p>Customer portal endpoints for order tracking, status monitoring, and customer-facing operations.</p>\n <div style=\"text-align: center; margin-top: 15px;\">\n <a href=\"https://api-docs.qargo.com/customer/docs\" style=\"\n display: inline-block;\n background: #6F82FB;\n color: white;\n padding: 12px 24px;\n text-decoration: none;\n border-radius: 6px;\n font-weight: bold;\n transition: background 0.3s;\n \">Customer Documentation</a>\n </div>\n</div>\n\n</div>\n\n# Authentication\n\nThe api requires oauth2 authentication with client id/secret. This should only be used for service to service communication.\n\n## Creating application credentials\n\nApplication client credentials can be created by users with the `Super admin` role in the Qargo application.\nUsers can create and remove application clients by navigating to Configuration -> Organisation Settings (API clients sections).\n\nApplications need to be linked to a valid integration id, identifying the Qargo approved integrator.\nPlease contact [us](mailto:integrations@qargo.com) if you don't have an id yet.\n\n## Obtaining an access token\n\nTo interact with the API, you need a valid access token in JWT (JSON Web Token) format. This token authenticates your requests and authorizes access to protected endpoints. The process involves using Basic Authentication to request the token via the `/auth/token` endpoint.\n\nThe [/auth/token endpoint](/docs/section/authentication/the-api-call-to-request-tokens) can be used to generate an access token (JWT):\n\nThis token will need to be refreshed after expiration (we provide the 'expires_in' in the token response to check validity).\n\n### Understanding Basic Authentication\n\nBasic Authentication is a simple HTTP authentication scheme that allows clients to provide credentials (such as a client ID and secret) directly in the request header. It works by encoding the credentials in Base64 and including them in the `Authorization` header of the HTTP request. For example:\n\n- **Format**: `Authorization: Basic <base64-encoded-credentials>`\n- **Credentials Encoding**: The client ID and secret are concatenated with a colon (e.g., `client_id:secret_id`) and then Base64-encoded.\n\n### The API Call to Request Tokens\n\nThe `/auth/token` endpoint is a POST request used to generate a JWT access token. You authenticate this request using Basic Auth with your provided `client_id` and `secret_id`.\n\n#### Request Details\n\n- **Method**: POST\n- **URL**: `https://api.qargo.com/v1/auth/token`\n- **Headers**:\n - `Content-Type: application/json`\n - `Authorization: Basic <base64-encoded-client_id:secret_id>`\n- **Body**: Empty.\n- **Parameters**: None.\n\nExample using `curl`:\n\n```\ncurl -XPOST https://api.qargo.com/v1/auth/token -H 'Content-type: application/json' -u '<client_id:secret_id>'\n```\n\n## Webhook authentication\n\n> **Important:** Webhook endpoints use a **different authentication method** than regular API endpoints. Do not use OAuth tokens for webhooks.\n\nQargo webhooks, such as those for order import and status updates, use **Basic Authentication** instead of OAuth. See [Understanding Basic Authentication](#understanding-basic-authentication) for details on the Basic Auth scheme.\n\nWebhook credentials (client id and secret id) are **provisioned by Qargo** when your webhook integration is configured — contact [integrations@qargo.com](mailto:integrations@qargo.com) to obtain them. They are **separate from your API credentials** and must be used exclusively for webhook endpoints.\n\n### API vs Webhook authentication summary\n\n| | **API endpoints** | **Webhook endpoints** |\n|---|---|---|\n| **Auth method** | OAuth2 (Client Credentials) | Basic Authentication |\n| **Credentials** | API client_id + secret_id → Bearer JWT token | Webhook client_id + secret_id (directly in header) |\n| **Header format** | `Authorization: Bearer <jwt_token>` | `Authorization: Basic <base64(client_id:secret_id)>` |\n| **Where to find credentials** | Configuration → Organisation Settings → API clients | Provisioned by Qargo — contact [integrations@qargo.com](mailto:integrations@qargo.com) |\n| **Token refresh needed?** | Yes (JWT expires) | No (credentials sent with each request) |\n\n### Common mistake\n\nWebhook credentials can technically be used to obtain an OAuth token via the `/auth/token` endpoint, but this token **will not work** for authenticating webhook requests. Always use Basic Authentication with your webhook credentials directly in the `Authorization` header.\n\n### Example webhook request\n\n```\ncurl -XPOST https://api.qargo.com/v1/webhook/order-import \\\n -H 'Content-Type: application/json' \\\n -u '<webhook_client_id>:<webhook_secret_id>' \\\n -d '{ ... }'\n```\n\n# Rate Limits\n\nTo maintain API stability and prevent abuse, we enforce rate limits on a per-tenant basis.\n\n### Limits\n\nThe limits below are estimates based on normal operating conditions. Under increased system load, these limits may be tightened without prior notice to protect API stability.\n\n| **Category** | **Scope** | **Limit** |\n| --- | --- | --- |\n| Authentication | `/auth/token` | 5 requests per hour |\n| General API Usage | All endpoints *except* authentication and webhooks | 2 requests per second (sustained); up to 3 per second (bursts) |\n\n### Enforcement\n\nRate limits are enforced by tracking requests over several sliding time windows-per second, per 10 minutes, and per hour. Exceeding any of these limits will result in an HTTP `429 Too Many Requests` response. The response includes a `Retry-After` header specifying the number of seconds your application should wait before making a new request.\n\nExample response:\n```http\nHTTP/1.1 429 Too Many Requests\nContent-Type: application/json\nRetry-After: 58\n\n{\"error\":\"Rate limit exceeded\"}\n```\n\nApplications must handle this response correctly by respecting the `Retry-After` header and retrying after the specified delay, regardless of whether the request appeared to be within the estimated limits.\n\nFor any concerns about these limits, please contact us at [integrations@qargo.com](mailto:integrations@qargo.com).\n\n# API Best Practices\n\nThis section outlines recommended practices for efficiently working with the Qargo API.\n\n## Pagination\n\nSome list endpoints support pagination. This means the endpoint offers a `next_cursor` in the response payload and accepts a `cursor` as query parameter. If pagination is supported and their response contains a `next_cursor` property, then you can use the `cursor` as a query parameter in a subsequent request to fetch the next page of results. Using query parameters is mutually exclusive with using the cursor.\n\n<br/>\n\n### How Pagination Works\n\n1. **Initial Request**: Make a request to a paginated endpoint without any cursor parameter\n2. **Check Response**: If the response includes a `next_cursor` field, more data is available\n3. **Subsequent Requests**: Use the `next_cursor` value as the `cursor` parameter in your next request\n4. **Continue**: Repeat until no `next_cursor` is returned\n\n<br/>\n\n### Example Usage\n\n```http\nGET /api/v1/orders\n```\n\nResponse:\n```json\n{\n \"data\": [...],\n \"next_cursor\": \"eyJpZCI6MTIzfQ==\"\n}\n```\n\nNext request:\n```http\nGET /api/v1/orders?cursor=eyJpZCI6MTIzfQ==\n```\n</br>\n\n### Recommendations\n\n- Always check for the presence of `next_cursor` before making additional requests\n- Store cursor values temporarily; they may expire after a certain period\n- Avoid using other query parameters when using cursor-based pagination\n\n## Backward compatibility\n\nThe Qargo API follows these backward compatibility principles:\n\n- **New fields may be added** to response payloads at any time. Adding new fields is **not** considered a breaking change.\n- **Integrators should ignore unknown fields** when parsing responses. Do not fail on unexpected properties.\n- **Deprecated fields and endpoints** are marked as `deprecated` in this specification. They continue to work but may be removed in a future version. Migrate to the recommended replacement as soon as possible.\n- **Existing fields will not be renamed or removed** without prior notice and a deprecation period.\n\n## Date and time formats\n\nAll date and time fields in the API follow ISO 8601:\n\n| Type | Format | Example | Description |\n|------|--------|---------|-------------|\n| Date | `YYYY-MM-DD` | `2024-12-31` | Calendar date without time component |\n| Datetime | `YYYY-MM-DDTHH:mm:ssZ` | `2024-12-31T14:30:00Z` | Timestamp in UTC (indicated by `Z` suffix) |\n| Time | `HH:mm` | `09:30` | Time of day in 24-hour format |\n\n- **Datetime fields are always in UTC.** Convert to local time on the client side.\n- **Date fields have no timezone.** They represent a calendar date (e.g. a planned delivery date).\n- **Time fields** are used for time windows (e.g. delivery windows) and are in 24-hour format without seconds.\n\n# Concepts\n\n## Company\n\nA company in Qargo can be both a customer as well as a subcontractor (supplier).\nThe entity will have a single id within Qargo. The api client can link companies by this id,\nor by the accounting code, which is a user defined code field.\n\n## Order\n\nTransport order to execute. Also called job in other TMS systems. It contains all transport details:\n\n- Order references\n- Customer [company](/docs/section/concepts/company)\n- Consigments, with their [stop](/docs/section/concepts/stop) locations, time windows, references\n- Definition of the goods to transport\n\n## Stop\n\n- A stop is a part of a transport, at a certain date, optional timeslot and location.\n In addition to the planned times, it also tracks the actual times for a completed stop.\n Stops can be linked to [orders](/docs/section/concepts/order), or can be defined standalone (for example a cleaning stop).\n All stops are linked to a Trip.\n\n### Stop group\n\nStops can be grouped together according to their activity and location. This is called a stop group.\n\n## Trip\n\nA trip contains [stops](/docs/section/concepts/stop) from various [orders](/docs/section/concepts/order), or standalone [stops](/docs/section/concepts/stop). It tracks how a certain\ntransport is planned, and who will execute that transport.\n\n## Task\n\nA task is the primary workflow concept in Qargo. Users can define their own flow,\nusing both built-in tasks as well a custom defined ones. For the current accounting use case,\nwe only expose the `post invoice/credit note` task, that allows users to send invoices to an accounting system.\n\n## Resource\n\nA resource in Qargo is a vehicle, driver, trailer or other entity that can be assigned to a [trip](/docs/section/concepts/trip).\n\n## Unavailability\n\nAn unavailability indicates that a specific [resource](/docs/section/concepts/resource) is not available for use for a given time range. An unavailability has a reason to indicate why the resource is not available.\n\n## Status update\n\nA status update reflects a status change in an entity.\n\n## Document\n\nA document in Qargo can be identified by a unique id. It has a type and is linked to a certain entity (for example an order).\n\n# Postman collection\n\nWe have a [postman](https://www.postman.com/downloads/) collection [available](/docs/postman.json \"download\")\nwith interactive examples (right click to download). Download this to a local folder, and import it into Postman for usage.\n\n### Instructions\n\n- Make sure you have a Postman client available. This can either be a local installed version or the web based version.\n- Request credentials for the Qargo API for order creation\n- Download and import the collection\n- Set the collection variables username and password with the credentials received\n- Execute the Request Access token request in the Authentication folder. You have now a valid access key for 1 hour. If you get the error message that the key is no longer valid, please refresh the access key by invoking this endpoint again.\n- You can now explore the different order endpoints\n\n# Functionality\n\nThe api exposes the following functionality:\n\n- Order management: create/update and get the status of transport orders.\n- Retrieve trip information: retrieve information about Qargo [trips](/docs/section/concepts/trip).\n- Visibility: send events to an external system using webhooks.\n- Order dispatch: send transport orders to a 3rd party using webhooks.\n- Accounting: interface an accounting system using the api endpoints.\n- Documents: interface to download documents\n\n## Order management\n\nAvailable functionality:\n\n- Create [orders](/docs/section/concepts/order) in Qargo and track order status.\n- Export any existing order to be used as a template for future order creation.\n\nThe api reference is available here: [order api](/docs/api-order).\n\n## Trip information\n\n[Trips](/docs/section/concepts/trip) can't be manipulated yet through the api, but it is possible to retrieve trip information.\nWe currently have an endpoint available to retrieve the charge information for a certain endpoint.\n\nYou can update the status of [stops](/docs/section/concepts/stop) and [stop groups](/docs/section/concepts/stop) of a trip using a [webhook](/docs/webhooks-inbound/subcontractor-status-update-webhook).\n\n## Resource management\n\n### Resource\n\n[Resources](/docs/section/concepts/resource) this should be used together with the endpoints to fetch unavailabilities as a resource unavailability is linked to a resource.\n\n### Unavailability\n\n[Resource unavailabilities](/docs/section/concepts/unavailability) can be managed through the API. The following operations are supported:\n\n- Creating an unavailability for a resource\n- Updating an unavailability for a resource\n- Deleting an unavailability for a resource\n- Fetching an unavailability for a resource\n- Fetching all unavailabilities for a resource\n\nThe goal of these endpoints is to allow external systems to manage the availability of resources in Qargo. An `external_id` is stored alongside the unavailability to allow for easy linking between the external system and Qargo. This `external_id` should be provided if a referential link is needed between the external system and Qargo.\n\nSee the [examples](/docs/section/resources/unavailabilities) on how to use the unavailability endpoints.\n\n## Visibility\n\nWe support visibility (sending messages triggered by Qargo system events) in the api as well.\nThese messages can be send out as a [webhook](/docs/webhooks-outbound/operational_visibility_event_webhook_post), or an EDI connection.\n\nFor most endpoints, visibility only trigger on status changes (for example, from stop `IN_PROGRESS` -> `COMPLETED`).\nThere are a few exceptions, these will be indicated in the overview:\n\n- Order level\n - We send out a visibility event on `ACCEPTED` (order created), `REJECTED` (order skipped) and `COMPLETED` (all stops for order completed).\n- Stop level\n - We send out a visibility event on `AT_STOP` (arrived at stop), `COMPLETED` (all activities completed for stop).\n- Position level (note: for every telematics update)\n- Trip level\n - We send a visibility event when a trip changes to `PLANNED` and when it transitions to `COMPLETED`.\n- Resource level\n - We send an event when a resource is assigned to a certain [trip](/docs/section/concepts/trip).\n\n## Order dispatch\n\nIt is also possible to subcontract trips to other parties. This is possible using two push endpoints:\n\n- Outgoing dispatched trip [payload](/docs/webhooks-outbound/subcontractor-dispatch-payload).\n- Incoming [message format](/docs/webhooks-inbound/subcontractor-status-update-webhook) to update subcontracted status.\n\n\n## Documents\n\nWe offer an interface to download documents. The documents can be fetched using the [document endpoints](/docs/api-document).\n\n## Request additional endpoints\n\nPlease contact [us](mailto:integrations@qargo.com) for inqueries regarding additional api functionality.\n\n# Transport order creation & status\n\nThis sections details how to construct payloads to create transport orders using the order upload endpoint([/orders/order/upload](/docs/api-order/import_order_v1_orders_order_upload_post)).\n\n## Order creation metadata\n\nOrders are not created synchronously via the API. When creating orders via the `POST /orders/order/upload` endpoint, you will receive the following response when creating an order.\n\n```json\n{\n \"upload_id\": \"<UPLOAD UUID>\",\n \"upload_status\": \"IN_PROGRESS\",\n \"upload_url\": \"v1/orders/order/upload/<UPLOAD UUID>\",\n \"order_id\": null,\n \"order_url\": null\n}\n```\n\nYou need to store the `upload_id` so you can fetch the status of the order creation by calling `GET /orders/order/upload/<UPLOAD UUID>`\n\nBased on the status of the upload (`upload_status`), you can know if the order is still in the progress of being created or has already been created. Both `order_id` and `order_url` will be filled in when the order has been created. The `order_id` will be filled in with the order id, which can then be used to fetch the order data and status from the system.\n\n**Example payload `GET /orders/order/upload/e01b3db1-4e49-4241-a91e-7534da884d46`** with a created order\n\n```json\n{\n \"upload_id\": \"e01b3db1-4e49-4241-a91e-7534da884d46\",\n \"upload_status\": \"COMPLETED\",\n \"upload_url\": \"v1/orders/order/upload/e01b3db1-4e49-4241-a91e-7534da884d46\",\n \"order_id\": \"a2a84715-0027-49af-ad30-494c0ccf75cc\",\n \"order_url\": \"v1/orders/order/a2a84715-0027-49af-ad30-494c0ccf75cc\"\n}\n```\n\n## Order identifier\n\nThe `order_identifier` is used to uniquely identify orders that are being created via the API. This means that the same `order_identifier` needs to be used when updating orders. Multiple identical updates after each other are idempotent and will not fail the request.\n\nThe `order_identifier` main usage is for `deduplication`, you cannot use the `order_identifier` to fetch an order.\n\n## Create an order\n\nThe first example is a simple transport from our london office to our Ghent office.\nPlease note that the transport service will need to be matched with the one in your system.\n\n```json\n{\n \"operation\": \"CREATE\",\n \"consignments\": [\n {\n \"delivery_stop\": {\n \"date\": \"2022-05-03\",\n \"location\": {\n \"name\": \"Qargo Ghent office\",\n \"address\": \"Gaston Crommenlaan 4\",\n \"postal_code\": \"9050\",\n \"city\": \"Ghent\",\n \"country\": \"BE\"\n },\n \"reference_number\": \"D12345\"\n },\n \"pickup_stop\": {\n \"date\": \"2022-04-21\",\n \"location\": {\n \"name\": \"Qargo London office\",\n \"address\": \"71-91 Aldwych\",\n \"postal_code\": \"WC2B 4HN\",\n \"city\": \"London\",\n \"country\": \"UK\"\n },\n \"reference_number\": \"P123456\"\n }\n }\n ],\n \"customer_reference_number\": \"T12345\",\n \"customer\": {\n \"code\": \"00020\"\n },\n \"order_identifier\": \"T1234393\",\n \"transport_service\": {\n \"name\": \"General\"\n }\n}\n```\n\nNote: it is possible to 'export' existing orders in the api to use as examples/templates.\nSee the [Export existing orders](/docs/section/transport-order-creation-and-status/export-an-existing-order) section.\n\n## Update an order\n\nThe following order is an update of an existing order. Note the `UPDATE` value of the operation field.\n\nImportant remarks:\n\n- Not all the fields of the order can be updated\n- the `order_identifier` field is used to identify the order to update\n\n**Example of an order update**\n\n```json\n{\n \"order_identifier\": \"QARGO_TEST_0001\",\n \"operation\": \"UPDATE\",\n \"customer\": {\n \"name\": \"UPS SCS Coventry\"\n },\n \"consignments\": [\n {\n \"pickup_stop\": {\n \"location\": {\n \"name\": \"Qargo HQ\",\n \"address\": \"Gaston Crommenlaan 4,\",\n \"postal_code\": \"9000\",\n \"city\": \"Gent\",\n \"state\": \"Oost-Vlaanderen\",\n \"country\": \"BE\",\n \"description\": \"Qargo HQ building\"\n },\n \"note\": \"Pickup 4 boxes of pasta\",\n \"date\": \"2024-08-20\",\n \"reference_number\": \"QACOLLI001\",\n \"planning_instructions\": \"If closed, call mobile number\",\n \"email\": \"info@qargo.com\",\n \"phone_number\": \"+0912341431\",\n \"mobile_number\": \"+324567890\"\n },\n \"delivery_stop\": {\n \"location\": {\n \"name\": \"Grocery store\",\n \"address\": \"Resedastraat 20\",\n \"postal_code\": \"9000\",\n \"city\": \"Gent\",\n \"state\": \"Oost-Vlaanderen\",\n \"country\": \"BE\",\n \"description\": \"Grocery store\"\n },\n \"note\": \"Don't forget to sign the documents\",\n \"date\": \"2024-08-21\",\n \"reference_number\": \"QADELIV001\",\n \"planning_instructions\": \"Alarm code: 123456\",\n \"email\": \"info@qargo.com\",\n \"phone_number\": \"02123456\",\n \"mobile_number\": \"+329998888\"\n },\n \"goods\": [\n {\n \"description\": \"4 boxes of pasta\",\n \"quantity\": 4\n }\n ]\n }\n ],\n \"customer_reference_number\": \"QARGO_TEST_0001\",\n \"transport_service\": {\n \"code\": \"CONTAINER_BOOKING\"\n }\n}\n```\n\n## Cancel an order\n\nTo cancel an order, pass `DELETE` as `operation` value. This will cancel the order. If the order has already been cancelled, this will not result in an error. Executing multiple cancellations is a idempotent operation and will not fail the request.\n\nA cancelled order cannot be uncancelled. If you need to revert the cancel, you will need to recreate the original order **using a different order identifier**. Using the same order identifier will cause the system to try to update the cancelled order, which results in an error.\n\n```json\n{\n \"operation\": \"DELETE\",\n \"consignments\": [\n {\n \"delivery_stop\": {\n \"date\": \"2022-05-03\",\n \"location\": {\n \"name\": \"Qargo Ghent office\",\n \"address\": \"Gaston Crommenlaan 4\",\n \"postal_code\": \"9050\",\n \"city\": \"Ghent\",\n \"country\": \"BE\"\n },\n \"reference_number\": \"D12345\"\n },\n \"pickup_stop\": {\n \"date\": \"2022-04-21\",\n \"location\": {\n \"name\": \"Qargo London office\",\n \"address\": \"71-91 Aldwych\",\n \"postal_code\": \"WC2B 4HN\",\n \"city\": \"London\",\n \"country\": \"UK\"\n },\n \"reference_number\": \"P123456\"\n }\n }\n ],\n \"customer_reference_number\": \"T12345\",\n \"customer\": {\n \"code\": \"00020\"\n },\n \"order_identifier\": \"T1234393\",\n \"transport_service\": {\n \"name\": \"General\"\n }\n}\n```\n\n## Export an existing order\n\nIt is possible to export a manually created order in the api. We first need to determine the technical id of this order.\n\n.\n\nThe order can be exported with the following endpoint:\n[Export order](/docs/section/transport-order-creation-and-status/export-an-existing-order).\nThe output of this endpoint corresponds to the order creation format. Just make sure to use a different [`order_identifier`](/docs/section/transport-order-creation-and-status/order-identifier), otherwise the 'new' order will be interpreted as an update.\n\n\n## Fetch order data and status\n\nWith the `GET /orders/order/<ORDER UUID>` [endpoint](/docs/api-order/get_order_details_v1_orders_order__order_id__get), you can fetch the data related to the order. This contains the current `status` of the order along with other data.\n\n## Container orders\n\nThere are 2 types of container orders that can be created using the API, `IMPORT` and `EXPORT`.\n\n### Import\n\nThis scenario contains of 2 main stops additional optional stops.\n\n1. Pickup of a loaded container\n2. Unload container\n3. Drop off empty container (Optional, configured in `teardown_stops`)\n\nThe `container_scenario` property is set as `IMPORT` and the drop off location of the container is specified in the the `teardown_stops` property. The optional `teardown_stops` describe the stops of the container after the consignment has been completed\n\n**Example `IMPORT` container scenario**\n\n```json\n{\n \"order_identifier\": \"QARGO_TEST_0002\",\n \"operation\": \"CREATE\",\n \"customer\": {\n \"name\": \"UPS SCS Coventry\"\n },\n \"teardown_stops\": [\n {\n \"location\": {\n \"name\": \"Container yard\",\n \"address\": \"Scheepzatestraat 1\",\n \"postal_code\": \"9000\",\n \"city\": \"Gent\",\n \"state\": \"Oost-Vlaanderen\",\n \"country\": \"BE\"\n },\n \"note\": \"Drop off the container on the designated location\",\n \"date\": \"2024-08-20\",\n \"reference_number\": \"CONT0001\",\n \"planning_instructions\": \"Put next to the red container\",\n \"email\": \"info@qargo.com\",\n \"phone_number\": \"+0912341431\",\n \"mobile_number\": \"+324567890\"\n }\n ],\n \"consignments\": [\n {\n \"pickup_stop\": {\n \"location\": {\n \"name\": \"Container pickup location\",\n \"address\": \"Gaston Crommenlaan 4,\",\n \"postal_code\": \"9000\",\n \"city\": \"Gent\",\n \"state\": \"Oost-Vlaanderen\",\n \"country\": \"BE\",\n \"description\": \"This is the container pickup location\"\n },\n \"note\": \"Pick up the green container\",\n \"date\": \"2024-08-20\",\n \"reference_number\": \"CONT0002\",\n \"planning_instructions\": \"Code of the container is 1234\",\n \"email\": \"info@qargo.com\",\n \"phone_number\": \"+0912341431\",\n \"mobile_number\": \"+324567890\"\n },\n \"delivery_stop\": {\n \"location\": {\n \"name\": \"Sports store\",\n \"address\": \"Resedastraat 20\",\n \"postal_code\": \"9000\",\n \"city\": \"Gent\",\n \"state\": \"Oost-Vlaanderen\",\n \"country\": \"BE\",\n \"description\": \"This is the delivery location of the container goods\"\n },\n \"note\": \"1000 boxes of shoes\",\n \"date\": \"2024-08-21\",\n \"reference_number\": \"CONT0003\",\n \"planning_instructions\": \"Use mobile number if gate is closed\",\n \"email\": \"info@qargo.com\",\n \"phone_number\": \"02123456\",\n \"mobile_number\": \"+329998888\"\n }\n }\n ],\n \"container\": {\n \"container_scenario\": \"IMPORT\"\n },\n \"customer_reference_number\": \"QARGO_TEST_0002\",\n \"transport_service\": {\n \"code\": \"CONTAINERS\"\n }\n}\n```\n\n### Export\n\nThis scenario contains 2 main stops with additional optional stops:\n\n1. Pickup empty container (Optional, configured in `setup_stops`)\n2. Load empty container\n3. Drop off loaded container\n\nThe `container_scenario` is set as `EXPORT` and the `setup_stops` property allows to define additional optional stops.\n\n**Example of an `EXPORT` `container_scenario`**\n\n```json\n{\n \"order_identifier\": \"QARGO_TEST_0003\",\n \"operation\": \"CREATE\",\n \"customer\": {\n \"name\": \"UPS SCS Coventry\"\n },\n \"setup_stops\": [\n {\n \"location\": {\n \"name\": \"Container yard\",\n \"address\": \"Scheepzatestraat 1\",\n \"postal_code\": \"9000\",\n \"city\": \"Gent\",\n \"state\": \"Oost-Vlaanderen\",\n \"country\": \"BE\"\n },\n \"note\": \"Pickup empty container on the designated location\",\n \"date\": \"2024-08-20\",\n \"reference_number\": \"CONT0001\",\n \"planning_instructions\": \"Blue container, next to the red container\",\n \"email\": \"info@qargo.com\",\n \"phone_number\": \"+0912341431\",\n \"mobile_number\": \"+324567890\"\n }\n ],\n \"consignments\": [\n {\n \"pickup_stop\": {\n \"location\": {\n \"name\": \"Container loading location\",\n \"address\": \"Gaston Crommenlaan 4,\",\n \"postal_code\": \"9000\",\n \"city\": \"Gent\",\n \"state\": \"Oost-Vlaanderen\",\n \"country\": \"BE\",\n \"description\": \"Qargo HQ, has a container loading bay\"\n },\n \"note\": \"Fill with 1000 boxes of Qargo shirts\",\n \"date\": \"2024-08-20\",\n \"reference_number\": \"CONT0002\",\n \"planning_instructions\": \"Code of the container is 1234\",\n \"email\": \"info@qargo.com\",\n \"phone_number\": \"+0912341431\",\n \"mobile_number\": \"+324567890\"\n },\n \"delivery_stop\": {\n \"location\": {\n \"name\": \"Train station container hub\",\n \"address\": \"Resedastraat 20\",\n \"postal_code\": \"9000\",\n \"city\": \"Gent\",\n \"state\": \"Oost-Vlaanderen\",\n \"country\": \"BE\",\n \"description\": \"This is the dropoff location of the loaded container\"\n },\n \"note\": \"1000 boxes of shoes\",\n \"date\": \"2024-08-21\",\n \"reference_number\": \"CONT0003\",\n \"planning_instructions\": \"Use mobile number if gate is closed\",\n \"email\": \"info@qargo.com\",\n \"phone_number\": \"02123456\",\n \"mobile_number\": \"+329998888\"\n }\n }\n ],\n \"container\": {\n \"container_scenario\": \"EXPORT\"\n },\n \"customer_reference_number\": \"QARGO_TEST_0003\",\n \"transport_service\": {\n \"code\": \"CONTAINERS\"\n }\n}\n```\n\n### Create a loaded container import transport order\n\nThe following order picks up a filled container, delivers it to our office, and returns the empty container.\nThis examples also demonstrates how to model ADR information.\n\n```json\n{\n \"operation\": \"CREATE\",\n \"consignments\": [\n {\n \"delivery_stop\": {\n \"location\": {\n \"name\": \"Qargo Ghent office\",\n \"address\": \"Gaston Crommenlaan 4\",\n \"postal_code\": \"9050\",\n \"city\": \"Ghent\",\n \"country\": \"BE\"\n },\n \"note\": \"unloading address comments\",\n \"reference_number\": \"D123956\"\n },\n \"pickup_stop\": {\n \"location\": {\n \"address\": \"Europaweg\",\n \"city\": \"Rotterdam\",\n
# --- truncated at 32 KB (134 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/qargo/refs/heads/main/openapi/qargo-api-task-api-openapi.yml