Florateck: A PrestaShop
Webservice API for Wholesale Resellers

Two dozen online stores can sell the same wholesaler’s products on the same morning, and every one of them needs three things to hold true at once: the items they list are actually in stock, the prices they show are the ones they personally negotiated, and each order a shopper places reaches the wholesaler without anyone re-keying it. Do that by hand across many resellers and it stops working. Catalogues drift out of date, prices go stale, and orders get lost in email.

That is the problem this project set out to solve. It is a PrestaShop Webservice API for wholesale resellers, built on top of Florateck Distribution’s own PrestaShop store, which stays the wholesaler’s system of record. Each reseller gets secure, scheduled access to Florateck’s catalogue, live stock, and their own custom prices, and can push their customers’ orders straight back into Florateck, all in JSON over HTTPS.

Put simply, one API key per reseller does two jobs at once. It applies that reseller’s negotiated pricing and it scopes every response to their own data and orders, so no partner ever sees another’s prices or customers. Scheduled synchronisations keep the data honest: catalogue and prices refresh nightly, stock and orders every four hours, so resellers never sell what is unavailable and orders keep moving.

The Starting Point: One Wholesaler, Many Resellers, Data That Must Line Up

Connecting a wholesaler to many e-commerce resellers by hand does not scale, because the same four things, catalogue, stock, price, and order data, have to stay lined up across every partner at the same time. Florateck needed one clear interface that every reseller could integrate against, not a pile of ad hoc file exports. The hard parts were specific:

• Stale catalogue and stock. Without an automated feed, resellers list products that are out of stock or no longer sold, which turns into failed orders and refunds.
• Per-reseller pricing. Each reseller has negotiated prices, so the same product costs a different amount depending on who is asking, and maintaining that by hand across many partners invites mistakes.
• Manual order handoff. Orders placed on a reseller’s own site still have to reach Florateck with the right products, quantities, delivery address, and reference, with no one re-typing them.
• Isolation and security. Every reseller must see only their own prices and orders and never another reseller’s, and every exchange has to be secure.
• The right cadence per data type. Stock and orders change often and need frequent updates, while the catalogue and price lists change slowly and can refresh overnight.

The Build: One Key for Pricing and Isolation, JSON for Everything Else

The API exposes exactly what a reseller needs, in JSON, and nothing they do not. A reseller reads the catalogue through GET /products and GET /products/{id}, with SKU, name, description, categories, image URLs, stock, and restock estimates. They check availability through GET /stocks, read their own negotiated prices through GET /prices, and track fulfilment through GET /orders/{id} and GET /orders/status. To place business, they call POST /orders with their reseller ID, the end customer’s contact and delivery details, the ordered SKUs and quantities, and their own order reference.

Every request is authenticated by a unique API key that maps to the reseller’s client ID, and that single identity is the heart of the design. It selects the reseller’s pricing and filters every response down to their own products, prices, and orders, so pricing and security run off one consistent mechanism rather than two systems that can disagree. Because the API is built on PrestaShop’s native webservice, it stays aligned with Florateck’s live store instead of a separate copy that drifts. This is the kind of API development work where the contract matters as much as the code.

For a reseller integrating for the first time, the path through the API runs in a clear order:

1. Authenticate with the reseller’s unique API key, which resolves to their client ID.
2. Pull the catalogue and current stock, so the storefront only lists what Florateck actually has.
3. Read the reseller’s own prices, resolved per client, and apply them on the storefront.
4. When a shopper checks out, submit the order with POST /orders under the reseller’s single Florateck account, carrying the end customer’s delivery details and the reseller’s reference.
5. Track the order through GET /orders/{id} and GET /orders/status until it is fulfilled.

Technical Architecture

Under the hood this is a secure, per-reseller data boundary layered on top of Florateck’s PrestaShop. The same catalogue and stock are shared across every reseller, while prices, orders, and visibility are scoped to each one by their key, and the whole thing stays current on a schedule. The architecture centres on a handful of subsystems, each mapped to a specific requirement.

• Key-based authentication and scoping. Every request carries the reseller’s API key, which resolves to a client ID; that ID both selects pricing and filters every response to the caller’s own products, prices, and orders.
• Custom pricing resolution. Prices are computed per client from database conditions tied to the client ID, so GET /prices returns the caller’s negotiated prices rather than one public list, with no duplicated price sheets to keep in sync.
• Order intake. POST /orders records each order under the reseller’s single Florateck account, capturing the end-customer contact, delivery address, SKUs and quantities, and the reseller’s reference, with only the delivery details changing from order to order.
• Scheduled synchronisation. Catalogue and prices refresh nightly while stock and orders refresh every four hours, matching each data type’s rate of change and preventing the sale of unavailable products.
• Secure transport and monitoring. All exchanges run over HTTPS, and performance monitoring with issue resolution keeps the integration dependable once it is live.
• Documentation as a deliverable. Two example-rich guides, one for Florateck and one for resellers, cover authentication, endpoints, payloads, and sample requests and responses.

Building on the PrestaShop Webservice rather than a bolt-on system was the decision that keeps the integration maintainable, since it reads and writes against the same store the merchandising team already runs. If you are extending a PrestaShop store into a partner-facing platform, our PrestaShop development team scopes which behaviours the webservice covers natively and which need custom endpoints on top.

Challenges Solved

The harder problems clustered around making one interface safe and correct for many partners at once. Tying pricing and isolation to a single API key removed the risk of the two ever falling out of step, and closed off any path for one reseller to reach another’s data. Resolving prices per client from database conditions, instead of duplicating price lists, left a single source to maintain as terms change. Matching sync cadence to how fast each data type moves kept availability accurate without wasting cycles re-syncing a catalogue that rarely changes.

The order path was the other place where a naive design would have leaked complexity. Recording every reseller order under one Florateck account, with only the delivery details varying, kept intake clean and predictable, and treating documentation as part of the scope rather than an afterthought let partners integrate against a clear contract. That combination suits retail and ecommerce businesses that resell a distributor’s range and need their storefront to reflect real stock and their own pricing without manual upkeep.

The Result

The outcome is a single, documented API that keeps every reseller’s catalogue, stock, prices, and orders continuously in step with Florateck. Fresh data on a schedule stops resellers selling what is not there. Correct pricing arrives automatically, resolved from each client ID. Reseller orders land in Florateck complete, with no re-keying. One key per reseller scopes every response, so isolation holds by design rather than by careful handling. And the two example-rich guides let new partners onboard quickly with a light support load.

The integration fits Florateck’s business because it is built on the store’s own system of record rather than a copy that can drift, so the API and the live catalogue never disagree. If you are connecting a wholesale operation to many storefronts, you can hire back-end developers who have built exactly this kind of scoped, key-per-partner API, or tell us about your distribution setup and we will map your resellers, pricing, and order flow to a clean interface.

Frequently Asked Questions

What is a PrestaShop Webservice API and why use it for reseller integration?

The PrestaShop Webservice is PrestaShop’s native API for reading and writing store data. Building a reseller integration on top of it keeps everything aligned with the merchant’s live catalogue, stock, and orders, its system of record, so partners integrate against the real store rather than a separate copy that can fall out of date.

How does one API key handle both pricing and data isolation?

Each reseller’s unique API key maps to a client ID. That single identity applies the reseller’s negotiated prices and filters every response to their own products, prices, and orders, so one consistent mechanism drives both pricing and security and there is no path for one reseller to reach another’s data.

How is the data kept up to date across resellers?

Scheduled synchronisation matches cadence to how fast each data type changes. Catalogue and prices refresh nightly, while stock and orders refresh every four hours, so availability stays accurate enough to prevent selling unavailable products without re-syncing slow-moving data more often than it changes.

How do reseller orders reach the wholesaler without manual re-entry?

A reseller submits an order through POST /orders with their reseller ID, the end customer’s contact and delivery details, the ordered SKUs and quantities, and their own reference. The order is recorded under the reseller’s single account with only the delivery details varying, so it arrives complete and no one re-keys it.

Can you build a partner or reseller API on top of an existing store?

Yes. Here the API was built on Florateck’s existing PrestaShop using the native webservice, with custom pricing resolution, order intake, scheduled sync, and per-key isolation added on top, plus documentation for both sides, so the store became a partner-facing platform without being rebuilt.