Svelte Commerce × PrestaShop
Svelte Commerce on PrestaShop
The PrestaShop connector works through the webservice API, and that API is the constraint: it has no customer login and no cart-to-order checkout. Browsing and the cart are wired; placing an order is not possible through it.
- 24/43 services wired
- @misiki/prestashop-connector 0.4.0
- Cart wired
- Checkout wired
- Sign-in (auth) no endpoint on the platform
What works on PrestaShop today
Shoppers can browse and fill a cart, but cannot sign in or place an order. Checkout counts as wired because the list of carriers comes from PrestaShop; the webservice API has no checkout or payment surface — placing an order is something only a front-office payment module can do — so every way the storefront places an order, cash on delivery included, is a placeholder.
Cart
Wired: issues a real request to PrestaShop.
Checkout
Wired: issues a real request to PrestaShop.
Sign-in (auth)
No endpoint on PrestaShop: it throws NotSupportedError rather than pretend.
Known gaps: auth, review, wishlist, payment-method
24 of 43 services wired, read from CONNECTORS.md on ; npm may carry a newer patch. How coverage is measured.
What the connector calls on PrestaShop
The connector calls PrestaShop’s REST webservice through its single /api gateway, forcing JSON responses with the Output-Format: JSON and Io-Format: JSON headers and sending every write as an XML body with Content-Type: text/xml, because the webservice reads no JSON input.
Every request carries HTTP Basic auth with the webservice key as the username and an empty password, which authenticates the shop rather than a shopper; there is no session or token to refresh, and shopper sign-in is not possible, so every auth method that would establish an identity throws NotSupportedError.
| Service | What it requests |
|---|---|
product | GET /api/products with display=full, filter[active]=[1], limit=offset,count and sort=[col_DIR]; a slug read is filter[link_rewrite]=[slug], completed by GET /api/combinations, /api/product_option_values, /api/product_options and /api/stock_availables |
search | GET /api/search?query=…&language=… for product ids, then GET /api/products?filter[id]=[a|b|c]&display=full |
category | GET /api/categories?filter[active]=[1]&sort=[position_ASC]; GET /api/categories/{id}?display=full for the product ids in associations.products |
cart | POST /api/carts with id_lang and id_currency; GET /api/carts/{id}?display=full; PUT /api/carts/{id} with the whole record; DELETE /api/carts/{id} |
checkout | GET /api/carriers?filter[active]=[1]&filter[deleted]=[0]&sort=[position_ASC] for shipping options |
order | GET /api/orders?display=full with filter[reference] and filter[id_customer]; GET /api/orders/{id}; GET /api/order_histories?filter[id_order]=[id] for tracking |
address | GET /api/addresses; POST /api/addresses; PUT /api/addresses/{id}; DELETE /api/addresses/{id} |
PrestaShop rules the connector follows
- PrestaShop has no count route, no pagination envelope and no total header, so the connector pages with
limit=offset,countfrom a 0-based offset and takes the total from a second request with the same filters and no limit, counting the ids it returns. - Sorting is sent as
sort=[date_add_DESC]and similar, and a sort ondate_addordate_updalso sendsdate=1, without which PrestaShop ignores it. /api/searchreturns bare product ids and answers 400 withoutlanguage, so search is two requests, the second afilter[id]=[a|b|c]list capped at 600 ids to keep the URL under the default 8 KB request-line limit.- A cart record carries no totals, so the connector computes them from catalogue prices as a tax-excluded estimate, and every cart change is a
PUTof the whole record withassociations.cart_rowsas a complete set; the cart id is kept inlocalStorageundercart_id. - The webservice key identifies the application, not a shopper, so
GET /api/orderswith no filter returns every order in the shop; the order list is scoped to one customer only when the caller passescustomerId, sent asfilter[id_customer].
Read from the source of misiki-in/prestashop-connector at commit 1d71757 of . Where the code has changed since, the code is right.
Quick start
From nothing to a Svelte Commerce storefront reading PrestaShop. You need Node.js and a PrestaShop to point it at; the storefront holds no data of its own.
Clone it, choose the connector, point it at PrestaShop
# 1 — get the storefront
git clone https://github.com/itswadesh/svelte-commerce
cd svelte-commerce
# 2 — one connector at a time: remove the two the storefront ships with, add this one
npm uninstall @misiki/litekart-connector @misiki/vendure-connector
npm i @misiki/prestashop-connector
# 3 — point it at your PrestaShop shop
echo PUBLIC_PRESTASHOP_API_URL=https://your-store.example.com >> .env
echo PUBLIC_PRESTASHOP_API_KEY=... >> .env
# 4 — run it
npm run devSwitching works the same way on every backend: what all 26 share, from one connector at a time to store identity.
Environment variables
| Variable | Required | What it does |
|---|---|---|
PUBLIC_PRESTASHOP_API_URL | Yes | Your PrestaShop shop’s URL. Boot fails, naming this variable, if it is missing. |
PUBLIC_PRESTASHOP_API_KEY | No | The webservice key from Advanced Parameters › Webservice. Every call needs it. See the limitations. |
PUBLIC_PRESTASHOP_LANGUAGE_ID | No | The shop’s language ID, sent as language=<id> so translatable fields come back as plain values rather than per-language arrays. |
PUBLIC_PRESTASHOP_SHOP_ID | No | Multistore shop ID (id_shop). Falls back to PUBLIC_PRESTASHOP_STORE_ID when unset. |
PUBLIC_PRESTASHOP_SHOP_GROUP_ID | No | Multistore shop group ID (id_group_shop). |
PUBLIC_PRESTASHOP_STORE_ID | No | Read as the shop ID when PUBLIC_PRESTASHOP_SHOP_ID is unset. |
PUBLIC_CONNECTOR | No | Only when more than one connector is installed: @misiki/prestashop-connector names the one this build runs on. |
init.ts hands the connector every PUBLIC_PRESTASHOP_* variable that is set, camel-cased. The guide also lists PUBLIC_PRESTASHOP_API_SECRET, PUBLIC_PRESTASHOP_ACCESS_TOKEN, PUBLIC_PRESTASHOP_ACCESS_KEY and PUBLIC_PRESTASHOP_CHANNEL_ID; the connector’s source does not read them.
Every variable here begins PUBLIC_, and SvelteKit sends PUBLIC_ variables to the browser: treat each value you set as published.
What to set up on PrestaShop
- Enable the webservice and create a key under Advanced Parameters › Webservice, with access to the resources the storefront reads — and read the limitations first.
How the integration works
The webservice API is PrestaShop’s back-office API, not a storefront one: it has no customer login and no cart-to-order flow. The connector reads the catalogue and manages carts through it, and lists the shop’s active carriers as shipping options — without prices, because PrestaShop computes those outside the webservice.
Writes need care: translatable fields must be sent with <language> children, and echoing a display=full read straight back silently blanks them — a bug the connector hit and fixed.
Limitations on PrestaShop
- The storefront cannot place an order. The webservice API has no checkout and no payment resource; placing an order is
PaymentModule::validateOrder(), which only a front-office payment module can call. So cash on delivery, Razorpay, Stripe and every other way the storefront places an order are placeholders on PrestaShop. - Shipping options come without prices: PrestaShop works them out from delivery ranges, zones and modules outside the webservice API.
- The webservice key the connector sends on every call comes from
PUBLIC_PRESTASHOP_API_KEY. SvelteKit sendsPUBLIC_variables to the browser, so every visitor to the store can read it and use whatever permissions the key has.
Before you rely on it
No connector has been exercised against a live production instance of its platform; each was written from the platform’s published source. The limits every backend shares and the errors every switch can meet are on the backends page.
An open question for PrestaShop’s maintainers: Is there a supported storefront auth path over the webservice API?
Offer a sandbox or a correctionFAQ
Questions about Svelte Commerce on PrestaShop
Can I run a PrestaShop store on Svelte Commerce today?
No. Shoppers can browse and fill a cart, but the webservice API has no shopper sign-in and no way to place an order — only a front-office payment module can do that — so every checkout path in the storefront is a placeholder.
How do I switch Svelte Commerce to PrestaShop?
Remove the connectors the storefront ships with, install @misiki/prestashop-connector, set PUBLIC_PRESTASHOP_API_URL in .env and start the dev server. vite.config.ts resolves whichever connector is installed, so no file in the storefront changes.
Why can’t shoppers sign in on PrestaShop?
The webservice API has no customer login endpoint, so the connector’s auth throws rather than fake a session. The Svelte Commerce maintainers have asked PrestaShop’s maintainers whether a supported storefront sign-in path exists over the webservice API.
Sources
PRESTASHOP.md, read on ; CONNECTORS.md, read on ; the connector’s source at 1d71757. Where they disagree with this page, they are right. PrestaShop is a trademark of its owner, named only to describe compatibility; see trademarks.