Model Context Protocol servers that expose these APIs to AI agents.
AsyncAPI definitions for this provider's event-driven and streaming APIs.
Authentication, domain security, vulnerability disclosure, and trust-center signals.
aid: ankorstore
name: Ankorstore
description: 'Ankorstore is a European B2B wholesale marketplace that connects independent brands with independent retailers
across Europe. Its public developer platform lets brands and their technical partners programmatically manage their presence
on the marketplace: sync product catalogs and stock, update prices, process and transition orders, request shipping quotes
and schedule pickups, manage Ankorstore Fulfillment Center replenishments, run OrderPay flows for a brand''s own customers,
and subscribe to real-time webhook notifications. The API is built on the JSON:API specification, secured with OAuth2 client
credentials, and ships alongside the ASTRAL stock-tracking/logistics API and a fulfillment media service, with a public
sandbox environment and a downloadable mock server for testing.'
url: https://raw.githubusercontent.com/api-evangelist/ankorstore/refs/heads/main/apis.yml
x-type: company
x-source: index-ventures-portfolio
x-tier: enriched
x-tier-reason: public-openapi-found
accessModel:
pricing: unknown
onboarding: self-serve
trial: false
try_now: false
public: false
label: Self-serve signup
confidence: medium
source:
- authentication
generated: '2026-07-22'
method: derived
specificationVersion: '0.20'
created: '2026-07-17'
modified: '2026-07-17'
image: https://cdn.ankorstore.com/images/logo/logo-black.svg
tags:
- Company
- Retail
- Wholesale
- Marketplace
- E-commerce
- Ordering
- Fulfillment
- Catalog
- Webhooks
- JSON:API
maintainers:
- FN: Kin Lane
email: kin@apievangelist.com
- FN: APIs.json
email: info@apis.io
- FN: Ankorstore Support
email: api@ankorstore.com
apis:
- aid: ankorstore:ankorstore-applications-api
name: Ankorstore Applications API
description: The Applications API from Ankorstore — 1 operation(s) for applications.
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Applications
properties:
- type: OpenAPI
url: openapi/ankorstore-applications-api-openapi.yml
- aid: ankorstore:ankorstore-brands-api
name: Ankorstore Brands API
description: The Brands API from Ankorstore — 8 operation(s) for brands.
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Brands
properties:
- type: OpenAPI
url: openapi/ankorstore-brands-api-openapi.yml
- aid: ankorstore:ankorstore-catalog-api
name: Ankorstore Catalog API
description: "ℹ️ This section describes the API endpoints that you can use to manage your catalog resources, such as products,\
\ product variants etc.\n\n## \U0001F4A1 Working with Products\n\nHere you will find information about the product resource\
\ and its sub-resources. If you need further information please refer to the API specification.\n\n### Including Product\
\ Variants\n\nWhen retrieving the individual product via the API, you may pass an `?include=productVariants` query parameter\
\ that will return associated product variants inside the `included` root level object.\n\n### Important Fields within\
\ Product Resource\n\nIf the field contains no data, it will be `null`.\n\n## \U0001F4A1 Stock Management\n\nThis API\
\ allows you to manage your product variants stock for the marketplace in both single- and bulk-operation mode.\nThere\
\ are 2 opposite options available for the stock update requests - set an explicit product quantity\nor mark the corresponding\
\ product as \"always in stock\".\n\n### Stock statuses\nStock for the marketplace can be in one of two states. It can\
\ be `available` to order on the marketplace, or `reserved` for an order that has been submitted, but not yet shipped.\n\
Added together, these quantities make up the `onHand` state, which reflects the total quantity of the product variant\
\ \"on hand\" at your storage location(s).\n\n> ⚠️ **Unless specified otherwise, `stockQuantity` used in the following\
\ APIs refers to `onHand` quantity**\n\nSee also [Stock State](#tag/folderName_Stock-Concepts/Stock-state) for more general\
\ information about stock states used in the Stock Tracking APIs.\n\n#### Example\n* 100 units of the product variant\
\ X are stock at your location (`onHand`).\n* 30 units of product variant X are `reserved` for Ankorstore orders that\
\ have not yet been shipped.\n* Then 70 units of product variant X are `available` to order on the marketplace.\n\nNow\
\ consider you produce 50 more units of product variant X, and sell 27 units on another marketplace. Your input for the\
\ stock update API would be:\n```\n// 100 + 50 - 27 = 133\n\"stockQuantity\": 123\n```\n\n### Set product variant stock\
\ explicit quantity\n\nTo set an explicit quantity for the particular product variant, you should specify the amount in\
\ the payload.\nIn case if the target product variant was previously marked as \"always in stock\", this option will be\
\ disabled and the stock\nwill be set to given value.\n\nExample of the payload to set a product variant stock to the\
\ given value (single-operation mode):\n\n`PATCH /api/v1/product-variants/1ed18988-6651-610e-8223-aa5cd9844f96/stock`\n\
```json\n{\n \"data\": {\n \"attributes\": {\n \"stockQuantity\": 123\n }\n }\n}\n```\nMore details can be\
\ found in the endpoint specification\n\n### Set product variant as \"always in stock\"\n\nTo mark a particular product\
\ variant as \"always in stock\" and do not care about the stock amounts, you should include a\nflag `isAlwaysInStock`\
\ into the request payload. In case if the target product variant had explicit stock amount set previously,\nit will be\
\ reset.\n\nExample of the payload to set a product variant stock to the given value (single-operation mode):\n\n`PATCH\
\ /api/v1/product-variants/1ed18988-6651-610e-8223-aa5cd9844f96/stock`\n```json\n{\n \"data\": {\n \"attributes\"\
: {\n \"isAlwaysInStock\": true\n }\n }\n}\n```\nMore details can be found in the endpoint specification\n\n\
### Update stocks of multiple product variants in single request (bulk-operation mode)\n\nThis API allows to update stocks\
\ of multiple product variants in single request. There is a specific endpoint which\naccepts up to 50 operations per\
\ request. Validation, business rules and payload of each operation is identical to the\nsingle-operation mode, described\
\ above.\n\nExample of the payload to update stocks of multiple product variants in single request:\n\n`POST /api/v1/operations`\n\
```json\n{\n \"atomic:operations\": [\n {\n \"op\": \"update\",\n \"data\": {\n \"type\": \"productVariants\"\
,\n \"id\": \"1ed18988-3253-610e-8223-aa5cd9844001\",\n \"attributes\": {\n \"isAlwaysInStock\"\
: true\n }\n }\n },\n {\n \"op\": \"update\",\n \"data\": {\n \"type\": \"productVariants\"\
,\n \"id\": \"1ed18988-6651-610e-8223-aa5cd9844f96\",\n \"attributes\": {\n \"stockQuantity\":\
\ 123\n }\n }\n }\n ]\n}\n```\nMore details can be found in the endpoint specification"
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Catalog
properties:
- type: OpenAPI
url: openapi/ankorstore-catalog-api-openapi.yml
- aid: ankorstore:ankorstore-catalog-exchange-api
name: Ankorstore Catalog Exchange API
description: The Catalog Exchange API from Ankorstore — 3 operation(s) for catalog exchange.
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Catalog Exchange
properties:
- type: OpenAPI
url: openapi/ankorstore-catalog-exchange-api-openapi.yml
- aid: ankorstore:ankorstore-catalog-integrations-api
name: Ankorstore Catalog Integrations API
description: "## \U0001F44B Getting Started\n\nThe catalogue integration process relies on the concept of operations. An\
\ operation is a batch of records\nrepresenting the products to create, update or delete. The completion state of an operation\
\ depends\non the execution result for every record it contains. It means an operation might fail without necessarily\n\
stopping or marking the whole operation as failed (this particular state is defined as “Partially failed”).\n\n- Operations\
\ can be of type `import`, `update` or `delete`.\n- Only one open operation (not yet started) is allowed at a time.\n\
- Only one operation can be performed (`started`) at a time.\n - Any subsequent operation will be queued with status\
\ `pending` until previous one has finished\nprocessing.\n - If no previous operation is being processed, operation will\
\ start processing right away.\n\n### Operation Statuses\n\nThe `status` attribute represents the current state of the\
\ operation, below is a table that describes each state:\n\n| Status | Description \
\ \
\ |\n|--------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n\
| `created` | The operation was created and not yet started. At this stage, the operation is considered open\
\ and products can still be added to the batch. |\n| `skipped` |\
\ The operation is empty and was skipped (No action required). When an operation is skipped, an empty report is generated\
\ and the callback URL is called to notify operation is completed. |\n| `started` | The operation started and\
\ is processing. \
\ |\n| `pending` | Operation is waiting for its turn on the processing\
\ queue. The operation could not be started because another one was being processed. \
\ |\n| `succeeded` \
\ | All products were successfully processed. \
\ |\n| `failed` | All products failed\
\ to be processed. \
\ |\n| `partially_failed` | Not all products were successfully processed.\
\ \
\ |\n\n## \U0001F4A1 Operation workflow\n\nThe complete workflow for an operation occurs in 3 stages:\
\ operation creation, operation processing and reporting.\nThe following diagram illustrates these stages and how they\
\ are chained.\n\n<pre class=\"mermaid\">\n%%{init: {\"flowchart\": {\"curve\":\"basis\", \"htmlLabels\":false, \"diagramPadding\"\
:24 } } }%%\ngraph LR\n\ncreated(\"Operation Created\")\nstart(\"Start Processing\")\nstarted(\"Processing\\nStarted\"\
)\nsucceeded(Succeeded):::success\nskipped(\"Processing Skipped\"):::success\npending(\"Operation pending\")\nfailed(Failed):::failure\n\
partial(Partially Failed):::warning\nreport(\"Report\\nGenerated\")\nnotified(Callback Sent)\n\nsubgraph creating[Creating\
\ Operation]\ncreated -- Add Products --> created\nend\n\ncreated -- Start Operation --> Start{?}\nStart -->|\"Another\
\ Operation execution in progress\"| pending\nStart --->|\"No other Operation in progress\"| start --> E{?}\nE -->|\"\
Batch.size > 0\"| processing\nE --->|\"Batch is empty\"| skipped\n\nsubgraph processing[Processing Operation]\ndirection\
\ LR\nstarted --> succeeded\nstarted --> partial\nstarted --> failed\nend\n\nsucceeded --> operationCompletedActions\n\
partial --> operationCompletedActions\nfailed --> operationCompletedActions\n\nsubgraph reporting[Reporting]\nreport --\
\ Notify --> notified\nend\n\nsubgraph triggerNext[Trigger next pending Operation]\nend\n\nsubgraph operationCompletedActions[Post-Complete\
\ Operation Actions]\nreporting\ntriggerNext\nend\n\npending -- Wait for previous Operation to finish execution --> start\n\
\nskipped -- Generate empty report --> operationCompletedActions\n\nclassDef default stroke:#4b475f,stroke-width:1px,fill:#ffffff,color:#4b475f\n\
classDef success stroke:#1aae9f,stroke-width:1px,fill:#cfeeeb,color:#293845\nclassDef failure stroke:#d3455b,stroke-width:1px,fill:#f6d8dd,color:#293845\n\
classDef warning stroke:#f7c325,stroke-width:1px,fill:#fdf2d1,color:#293845\nlinkStyle default stroke:#788896,stroke-width:1px,fill:transparent\n\
</pre>\n\n### Creating an Operation\n\nThe full flow of creating a complete operation consists in two steps:\n\n#### 1.\
\ Create a new operation\n\nSend a `POST` request to `/api/v1/catalog/integrations/operations`\n\nExample request:\n```json\n\
{\n \"data\": {\n \"type\": \"catalog-integration-operation\",\n \"attributes\": {\n \"source\"\
: \"shopify\",\n \"callbackUrl\": \"https://callback.url/called/after/processing\",\n \"operationType\"\
: \"import\"\n }\n }\n}\n```\n\n- At this point the new operation has been created and waiting to receive products\
\ data\n- Operation ID will be returned in the response payload\n\n#### 2. Add product data to operation\n\nSend a `POST`\
\ request to `/api/v1/catalog/integrations/operations/{operationId}/products`\n\nProducts can be added only to operations\
\ with status `created`.\n\nIf operation has been started already (having any of `started`, `pending`, `skipped`, `succeeded`,\
\ `partially_failed`, `failed`, `cancelled` status),\nthe request will fail with a `403 Forbidden` status code.\n\nExample\
\ request:\n```json\n{\n \"products\": [\n {\n \"id\": \"B006GWO5WK\",\n \"type\": \"\
catalog-integration-product\",\n \"attributes\": {\n \"external_id\": \"B006GWO5WK\",\n \
\ \"name\": \"Example product\"\n // ...\n }\n }\n ]\n}\n```\n\nYou can\
\ perform as many requests as needed to append product data during this stage.\n\n### Operation Processing\n\nIn order\
\ to start processing the operation, you have to send a `PATCH` request\nto `/api/v1/catalog/integrations/operations/{operationId}`\
\ with the expected operation status (i.e. “started”).\n\nIf there is any other operation being executed at that time,\
\ the operation will be enqueued to be processed\nwith the status `pending` and will be started as soon as it gets a free\
\ slot in the queue. Otherwise, the\noperation will be started right away.\n\nExample request:\n```json\n{\n \"data\"\
: {\n \"id\": \"90567710-de47-49e4-8536-aab80c1a469c\",\n \"type\": \"catalog-integration-operation\",\n\
\ \"attributes\": {\n \"status\": \"started\"\n }\n }\n}\n```\n\n### Execution Report\n\n\
When an operation completes, an execution report is generated.\nIt provides the execution results (success or failure)\
\ for every product of the operation.\n\nYou can access this report by reading from the following endpoint.\n\n```http\n\
GET /api/v1/catalog/integrations/operations/{operationId}/results\n```\n\n## \U0001F4A1 Event Callbacks\n\nCallbacks enable\
\ you to get notified when events occur in the operation process. For example, you can\nconfigure a callback to notify\
\ you when the operation is completed. The notification is sent via\nan HTTP request to the URL you specify in the operation\
\ settings.\n\nCallbacks can be used to trigger automated actions in your integration.\n\n### Supported events\n\nYou\
\ can find here below the complete list of all the topics `{{resource}}.{{event}}` you can monitor:\n\n| Topic \
\ | Trigger \
\ |\n|-------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|\n\
| `catalog-integration-operation.completed` | An operation reaches a completed state such as **Success**, **Failed**,\
\ or **Partially Failed** |\n| `catalog-integration-operation.cancelled`\
\ | An operation was cancelled. This event is triggered when an operation processing is **Skipped** (i.e. the operation\
\ batch is empty and no action is required). |\n\n### Event schema\n\nA callback event is represented as a JSON object\
\ and has the following properties:\n\n- `event` — the name of the event that occurred (e.g. “completed”)\n- `topic` —\
\ the event category represented as a unique identifier of the event type.\n The topic is defined as a concatenation\
\ of the resource and event names `{$.data.type}.{$.event}`,\n e.g. “catalog-integration-operation.completed”. You might\
\ use this topic as a partition key to distribute\n the callback events you receive to separate queues or pools of workers\
\ to process the callbacks\nasynchronously. - `occurredAt` — the date and time when the event occurred\n- `data` — the\
\ JSON:API resource describing the state of the entity which triggered the callback\n\nA callback event is delivered as\
\ a `POST` request to your endpoint. The following payload represents the notification\nrequest that is triggered when\
\ an operation successfully completes:\n\n```json\n{\n \"event\": \"completed\",\n \"topic\": \"catalog-integration-operation.completed\"\
,\n \"occurredAt\": \"2024-03-21T13:42:54+00:00\",\n \"data\": {\n \"id\": \"90567710-de47-49e4-8536-aab80c1a469c\"\
,\n \"type\": \"catalog-integration-operation\",\n \"attributes\": {\n // ...\n \"\
status\": \"succeeded\",\n \"createdAt\": \"2024-03-21T13:13:03+00:00\",\n \"startedAt\": \"2024-03-21T13:19:32+00:00\"\
,\n \"completedAt\": \"2024-03-21T13:42:54+00:00\"\n // ...\n }\n }\n}\n```\n\n### Handling\
\ callbacks\n\nThe endpoint listening for callbacks has **3 seconds** to respond with a `2xx` (usually `200`)\nresponse\
\ code, acknowledging a successful delivery. If the request times out or gets a response\nwith a status code other than\
\ `2xx`, it is considered failed.\n\n<div class=\"warning\">\n\n#### Handling webhook failures\n\nIf a callback fails\
\ (whatever the reason) no further calls to the related endpoint are made.\n</div>\n\n### Testing callback\n\nA number\
\ of websites, such as https://webhook.site and https://requestbin.com, provide free URLs that\ncan be used to test callbacks.\
\ Simply create a URL on one of these sites, then configure your webhook\nto use it. These sites allow you to see the\
\ details of the request sent to them by the callback service.\n\nIn addition, the Ngrok service (https://ngrok.com) allows\
\ you to tunnel callback requests to a non-publicly\naccessible server, enabling you to test your callback-handling code\
\ before making it public.\n\n### Operations and Drafts behaviour\n\n| Type | Behaviour \
\ \
\ |\n|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n\
| `import` | When executing an import operation existing drafts will be cleaned and new ones will be created if any of\
\ the products attached to the operation has any validation issue. |\n| `update` | Will not have any impact on existing\
\ drafts. \
\ |\n| `delete` | Will not have any impact on existing drafts. \
\ |"
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Catalog Integrations
properties:
- type: OpenAPI
url: openapi/ankorstore-catalog-integrations-api-openapi.yml
- aid: ankorstore:ankorstore-deprecated-api
name: Ankorstore Deprecated API
description: 'ℹ️ Here you can find the endpoints which are currently deprecated and will be removed in the future versions
of the API.
We strongly encourage you to migrate away from these endpoints in order to prevent any future problems with API.
## ❄️ Shipping an Order
| ⚡ This documentation is deprecated |
|------------------------------------|
### Schedule a Pickup
If the brand is not taking the parcels to the local drop-off point for the carrier the brand can schedule a pickup for
this order. A pickup can only be scheduled on a working day (monday to friday). For full information please refer to the
API documentation.
<div class="info">
#### Pickup is not accepted
For now, Ankorstore does not know in advance which date/time configuration is available, if the requested pickup is denied
please try a different date or time frame.
</div>'
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Deprecated
properties:
- type: OpenAPI
url: openapi/ankorstore-deprecated-api-openapi.yml
- aid: ankorstore:ankorstore-fulfillment-api
name: Ankorstore Fulfillment API
description: "ℹ️ Here you can find the information and endpoint specification related to fulfillment of the orders.\n\n\
## \U0001F4A1 About Fulfillment\n\n_Fulfillment_ is the process of preparing and shipping orders to customers via Ankorstore\
\ Fulfillment Centers.\nBrands that use fulfillment send their inventory to a warehouse in advance, and when orders come\
\ in, the warehouse\npicks, packs, and ships on the brand's behalf.\n\n### What does \"fulfillable\" mean?\n\nThe concept\
\ of a \"fulfillable\" is _that which is required to prepare and ship a product (variant)_.\nWhile a Fulfillment Centre\
\ deals exclusively with items, which represents a single item that an employee can pick up and prepare for shipping.\n\
A fulfillable is simply a set of one or more items, that together represent a product as ordered.\n\nUse the [List Fulfillables](#tag/Fulfillment/operation/fulfillment-list-fulfillable)\
\ endpoint to check stock\navailability for specific product variants before creating orders. For more detailed stock\
\ information —\nincluding quantities by location, status, and lot — use the\n[Stock State endpoint](/api/astral/v1/stock/state)\
\ from the Ankorstore Stock Tracking and Logistics API (ASTRAL).\n\n### Fulfillments\n\nWhen a _Master Order_ has fulfillment\
\ requested, one or more _Fulfillments_ are created. Multiple fulfillments\ncan be associated with a single master order\
\ (many-to-one). You can retrieve their details and track progress\nthrough the following statuses:\n\n| Status | Description\
\ |\n| --- | --- |\n| `requested` | Fulfillment has been requested for the order |\n| `created` | Fulfillment has been\
\ created in the warehouse system |\n| `scheduled` | Fulfillment is scheduled for picking |\n| `released` | Fulfillment\
\ has been released for picking |\n| `shipped` | Fulfillment has been shipped from the warehouse |\n| `cancelled` | Fulfillment\
\ has been cancelled |\n| `cancellation_requested` | A cancellation has been requested but not yet processed |\n\nPass\
\ `?include=statusUpdates` when retrieving a fulfillment to see the full history of status transitions.\n\n### Lots\n\n\
If your products are lot-tracked or expiry-tracked, the [List Lots](#tag/Fulfillment/operation/fulfillment-list-lots)\n\
endpoint shows the current lot inventory in the warehouse, including lot numbers, available quantities, and\nexpiry/sell-by\
\ dates. You can filter and sort by available quantity, sell-by date range, and product name.\n\n### Fulfillment Costs\n\
\nUse the [Get Fulfillment Costs](#tag/Fulfillment/operation/fulfillment-costs-get-specifications) endpoint to estimate\n\
fulfillment costs before committing to an order. Provide the destination country, parcel dimensions, and picking\nquantity\
\ to receive a cost breakdown by category (shipping, pick fees by quantity tier).\n\n> ⚠️ The cost estimation does **not**\
\ include packing consumables. The actual invoiced amount may differ.\n\n## Replenishments\n\nReplenishments are required\
\ to send inventory to the warehouse. They follow a specific workflow:\n\n### Replenishment Workflow\n\n<pre class=\"\
mermaid\">\nstateDiagram-v2\n direction LR\n [*] --> created\n created --> confirmed : Brand confirms\n confirmed\
\ --> sent : Sent to warehouse\n sent --> delivered : Arrives at warehouse\n delivered --> received : Items put\
\ into stock\n received --> [*]\n</pre>\n\n* **Created**: When a replenishment is initially created, it will be at\
\ status `created` and is considered a draft. In this state, it can be edited via PATCH requests or deleted.\n* **Confirmed**:\
\ Once editing is complete, the status should be updated to `confirmed` as part of a PATCH request. At this point, the\
\ replenishment information will be sent to the warehouse (asynchronously).\n* **Sent**: Once the replenishment information\
\ is sent to the warehouse, the status changes to `sent`. The replenishment will remain in this status while waiting for\
\ delivery.\n* **Delivered**: When the replenishment physically arrives at the warehouse, its status will be automatically\
\ updated to `delivered`.\n* **Received**: Once the items are put into stock at the warehouse, the status will be updated\
\ to `received`. At this stage, receipts are added with the received stock quantities and lots.\n\n### Creating a Replenishment\n\
\nEach replenishment requires a carrier name, shipment type, and a list of items with their fulfillment item IDs\nand\
\ quantities:\n\n```json5\n// POST /api/v1/fulfillment/replenishments\n{\n \"fulfillmentBrandId\": \"a1b2c3d4-e5f6-7890-abcd-ef1234567890\"\
,\n \"warehouseId\": \"98765432-abcd-ef01-2345-678901234567\",\n \"shippingCarrierName\": \"DHL\",\n \"shipmentType\"\
: \"PARCEL\", // \"LTL\", \"FTL\", or \"PARCEL\"\n \"items\": [\n {\n \"fulfillmentItemId\": \"d290f1ee-6c54-4b01-90e6-d701748f0851\"\
,\n \"quantity\": 100\n }\n ]\n}\n```\n\nAfter creating a replenishment, update its status to `confirmed` via\
\ PATCH when you are ready to notify the warehouse.\n\n### How Fulfillment Connects to Orders\n\nThe diagram below shows\
\ how fulfillment fits into the order lifecycle:\n\n<pre class=\"mermaid\">\ngraph LR\n A[Master Order] --> D[Fulfillment\
\ 1]\n A --> E[Fulfillment 2]\n F[Replenishment] --> G[Warehouse Stock]\n G --> D\n G --> E\n</pre>\n\n1.\
\ Brands send inventory to the warehouse via _Replenishments_\n2. When fulfillment is requested for a _Master Order_,\
\ one or more _Fulfillments_ are created\n3. The warehouse picks items from stock and ships each fulfillment\n4. Use the\
\ fulfillment endpoints to track both your inventory and fulfillment status"
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Fulfillment
properties:
- type: OpenAPI
url: openapi/ankorstore-fulfillment-api-openapi.yml
- aid: ankorstore:ankorstore-general-api
name: Ankorstore General API
description: 'ℹ️ This section contains general-purpose endpoints that are transversal to the system. These endpoints provide
reference data useful across different integration scenarios.
## 💡 Currency Rates
The currency rates endpoint returns the latest exchange rates used by the Ankorstore platform.
> ⚠️ This endpoint is **public** and does **not** require authentication.
```
[GET] /api/v1/currencies/rates/latest
```
Each rate entry contains:
- `fromCurrency` - The source currency code (e.g., `"USD"`)
- `toCurrency` - The target currency code (e.g., `"EUR"`)
- `rate` - The exchange rate as a decimal number
- `date` - The date of the rate
This is useful when your integration needs to display prices in multiple currencies or reconcile amounts across
different currency zones.'
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- General
properties:
- type: OpenAPI
url: openapi/ankorstore-general-api-openapi.yml
- aid: ankorstore:ankorstore-integration-api
name: Ankorstore Integration API
description: The Integration API from Ankorstore — 1 operation(s) for integration.
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Integration
properties:
- type: OpenAPI
url: openapi/ankorstore-integration-api-openapi.yml
- aid: ankorstore:ankorstore-locations-api
name: Ankorstore Locations API
description: The Locations API from Ankorstore — 1 operation(s) for locations.
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Locations
properties:
- type: OpenAPI
url: openapi/ankorstore-locations-api-openapi.yml
- aid: ankorstore:ankorstore-media-api
name: Ankorstore Media API
description: Operations for documents linked to fulfillment requests
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Media
properties:
- type: OpenAPI
url: openapi/ankorstore-media-api-openapi.yml
- aid: ankorstore:ankorstore-movements-api
name: Ankorstore Movements API
description: The Movements API from Ankorstore — 2 operation(s) for movements.
humanURL: https://ankorstore.github.io/api-docs/
baseURL: https://www.ankorstore.com
tags:
- Movements
properties:
- type: OpenAPI
url: openapi/ankorstore-movements-api-openapi.yml
- aid: ankorstore:ankorstore-ordering-api
name: Ankorstore Ordering API
description: "ℹ️ This section of API allows to manage different types of orders in the system. Depending on the order type,\
\ there are\ndifferent endpoints available to manage them. Before starting to work with the API, it is recommended to\
\ read the\ndocumentation to better understand the differences between the order types, their workflow and lifecycle.\n\
\n## \U0001F4A1 General conceptions\n\n- _Internal Order_ - A regular type of order created via Ankorstore platform. It\
\ may have different types of shipping\n and payment.\n The client of such an order is always an existing retailer entity,\
\ available in Ankorstore.\n- _External Order_ - A special type of order created by a brand for an external customer,\
\ which might not exist in\n Ankorstore. This type of order does not expect retailer as a reference to the Ankorstore\
\ entity,\nbut rather allows brand\n to provide a custom client details, such as address, contact information etc. The\
\ orders of this\ntype in the\n current version of the platform are fulfilled by the Fulfillment Centers only and do\
\ not support\nany other type of shipping. - _Master Order_ - Not a separate type of order, but rather a wrapper over\
\ other order types.\n It allows to have a single reference to the order, regardless of its type. A _Master Order_ usually\n\
has a one-to-one\n relationship with either _Internal Order_
# --- truncated at 32 KB (91 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/ankorstore/refs/heads/main/apis.yml
Kin Score
How this is scored →