Skip to content

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/v1
  • 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.

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.

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.

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 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 whose external_id already 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_hours and pickup_hours, each replaced as a whole when you send it.
  • Attach a listing to a store by sending store_id (the Kreezalid id) or store_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.
  • Writes answer with success. Like the Admin API, refused writes answer 200 with "success": false and a message. 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’s supplier_id.
  • One vendor per credential. A chain with several vendor accounts needs one credential per account.