Partners API
The Partners API is the API of one vendor. Where the Admin API sees the whole marketplace, a Partners API credential sees only the listings, orders, stores and shipping rates of the vendor account it belongs to. It is built for the vendor’s own back-office systems: a retailer’s ERP that pushes its stock, a brand’s PIM that publishes its products, a chain’s store directory.
https://<primary address>/api/partners/v1Typical integrations
Section titled “Typical integrations”- Catalog sync from the vendor’s PIM or ERP: create and update listings, prices and stock, attach them to a shop.
- Order fulfilment in the vendor’s order management: read the vendor’s orders, update their status and tracking.
- Store directory: publish the vendor’s shops, counters and pickup points with their opening hours, and replay the whole list on a schedule.
Authentication
Section titled “Authentication”HTTP Basic with an API key and secret that belong to the vendor. There is no self-service screen for these credentials yet: request them from Kreezalid support for a given marketplace and vendor account. See Authentication.
Resources
Section titled “Resources”| Resource | Endpoints |
|---|---|
| Listings | List · Retrieve · Create · POST /listings/bulk · Update · Delete |
| Listing set-up | GET /listings/categories · GET /listings/attributes · GET /listings/order_types |
| Orders | List · Retrieve · Update |
| Shipping rates | List · Retrieve |
| Stores | List · Create or update by code · Retrieve · Update · Delete |
Listings and orders have the same shape as in the Admin API. The Partners API reference documents every field.
How it differs from the Admin API
Section titled “How it differs from the Admin API”| Admin API | Partners API | |
|---|---|---|
| Scope | The whole marketplace | One vendor’s listings, orders, stores and shipping rates |
| Owner of a created listing | The user_id you send |
Always the vendor of the credential |
| Moderation on creation | admin_status and visibility as you send them |
Always created approved, visible in catalog and search |
| Listing filters | user_id, category_id, status, admin_status, order_type_id, on_homepage |
category_id, status, admin_status, order_type_id |
| Order filters | status, id, order_number, customer_id, supplier_id, cart_id, start_on_date |
status, id, order_number, customer_id, cart_id, start_on_date, always within the vendor’s orders |
| Users, events, collections, metafields | Yes | No |
| Stores | No | Yes |
A listing, an order or a store of another vendor answers 404, exactly like one that does
not exist.
Stores
Section titled “Stores”Stores are the vendor’s physical places: shops, counters, warehouses, pickup points. They
exist on marketplaces that use multiple stores; elsewhere, /stores answers 404.
- Give each store your own code in
external_id. Posting a store whoseexternal_idalready exists updates it instead of creating a duplicate, so you can send the complete list again on every sync. - Stores carry an address, coordinates, a phone number, flags (
is_active,is_default,is_pickup_point,display_in_locator),pickup_instructions, and two weekly schedules,opening_hoursandpickup_hours, each replaced as a whole when you send it. - Attach a listing to a store by sending
store_id(the Kreezalid id) orstore_external_id(your code) with the listing. Not both. The listing then shows at the store’s address, and buyers are told where to collect it.
Things to know
Section titled “Things to know”- Writes answer with
success. Like the Admin API, refused writes answer200with"success": falseand amessage. See Errors. - Some errors are HTML. Authentication failures and missing resources return the right status code with an HTML body. Check the status before parsing.
- Orders: send
PATCH /orders/{id}with the fields to change, for instance{"status": "shipped"}once the parcel has left; the vendor cannot change the order’ssupplier_id. - One vendor per credential. A chain with several vendor accounts needs one credential per account.