The full specification is one self-contained document, small enough to read in one pass, and states the semantics rather than just the field names. You should not need to summarise this page for it.
Paste this into your assistant:
Integrate the Eckstein Partner API. Fetch the full specification from https://app.eckstein.pro/partnerapi/v1/openapi.json — one self-contained document with every endpoint, field, semantic rule and worked example you need. Read info.description for what holds across the API, then the description of each operation you call: the rules for reading its rows live there and are not repeated.
Six rules whose violation is silent — a client that breaks them looks like a working one, so verify each against the spec rather than assuming:
1. Set a User-Agent naming your integration on every request. Several HTTP libraries send a default agent the edge refuses with a 403, which is not an authentication error and says nothing about the key.
2. Two speeds. Crawl /products once, then poll /products?changed_since= for catalogue edits; poll /availability for stock. Never re-crawl the catalogue to find stock — stock is not in it.
3. supply_interrupted is a judgement, not a quantity. Roughly one marked article in seven still has units we can ship today. Order against available_now; do not gate on the flag.
4. POST /orders returns a receipt, not an order. Poll /orders/requests/{order_reference} for the decision, and handle accepted_with_changes as its own case — it means the order we accepted differs from the one you sent, and its lines are the ones that count.
5. Send exactly the documented request shape. Unknown or misspelled fields are refused, deliberately: a dropped delivery_address would ship goods to the wrong party with nothing looking wrong.
6. Ignore response fields you do not recognise, and treat every date field as nullable. We add fields without notice and null carries meaning.
One thing to raise with your team rather than decide yourself: if you will send delivery_address for shipments to your own customers, Eckstein runs no deliverability check and ships exactly what you send. Ask which system on your side validates an address before it reaches us, and what happens when it fails — report the answer, including if there is none. Do not implement address validation in the client: that is a decision about your shipping process, not about this API.
Worth stating explicitly:
delivery_date and
estimated_replenishment_date are
nullable, not optional — always present, and
null means something. A client that models them as
optional will drop the rows where they matter most.
401 is terminal. Do not wrap it in retry logic.
The client you build must set a
User-Agent naming itself, on every request.
Several HTTP libraries send a default agent that the edge network
refuses as a scraper (Python-urllib among them); the
resulting 403 is not ours and is not about your key.
Specification: https://app.eckstein.pro/partnerapi/v1/openapi.json