Svelte Commerce × Spryker
Svelte Commerce on Spryker
Spryker’s storefront API speaks JSON:API, and the connector wires browsing, cart, sign-in and Spryker’s checkout data. The storefront cannot place an order on it yet: Spryker has no per-gateway checkout, and the storefront asks for one.
- 25/43 services wired
- @misiki/spryker-connector 0.4.0
- Cart wired
- Checkout wired
- Sign-in (auth) wired
What works on Spryker today
Browsing, cart and sign-in are wired, but the storefront cannot complete an order yet. Spryker has two checkout endpoints and no per-gateway ones, with payment methods named per store. The connector offers getCheckoutData() and placeOrder() for that, but the storefront’s payment step calls one method per gateway — cash on delivery included — and each of those is a placeholder.
Cart
Wired: issues a real request to Spryker.
Checkout
Wired: issues a real request to Spryker.
Sign-in (auth)
Wired: issues a real request to Spryker.
Known gaps: coupon
25 of 43 services wired, read from CONNECTORS.md on ; npm may carry a newer patch. How coverage is measured.
What the connector calls on Spryker
The connector calls Spryker’s Glue Storefront API, a JSON:API surface with no path prefix (/catalog-search, /abstract-products/{sku}, /carts, /checkout and so on hang off the configured host), and only its POST /token route takes form-encoded input and answers in flat JSON.
A shopper signs in with an OAuth password grant to POST /token, sent as application/x-www-form-urlencoded, and the access token is then sent as Authorization: Bearer <token> and renewed once with the refresh token when a call answers 401; a guest is identified only by X-Anonymous-Customer-Unique-Id, which the connector mints itself and keeps in localStorage and a cookie.
| Service | What it requests |
|---|---|
product | GET /catalog-search with q, page, ipp, sort and category for lists, and GET /abstract-products/{sku}?include=concrete-products,abstract-product-image-sets,abstract-product-prices,abstract-product-availabilities for one product, after GET /url-resolver?url= turns a slug into the SKU |
search | GET /catalog-search for results and GET /catalog-search-suggestions?q= for typeahead |
category | GET /category-trees and GET /category-nodes/{nodeId}, with GET /url-resolver?url= for a category slug |
cart | GET /carts or /guest-carts with include=items or guest-cart-items, POST /carts/{uuid}/items or POST /guest-cart-items, PATCH on {root}/{uuid}/{items|guest-cart-items}/{groupKey}, and POST {root}/{uuid}/vouchers |
payment-method | POST /checkout-data?include=payment-methods for the current cart, since there is no standalone payment-methods route |
auth | POST /token (grant_type=password), then GET /customers for the profile; POST /customers to register and DELETE /refresh-tokens/{token} on sign-out |
order | GET /orders with page[offset] and page[limit], and GET /orders/{id} |
address | GET, PATCH and DELETE on /customers/{customerReference}/addresses and /customers/{customerReference}/addresses/{id} |
Spryker rules the connector follows
/catalog-searchpages withpageandippand is the only route that reports a real total (pagination.numFound);/ordersand the other offset routes takepage[offset]andpage[limit]and return onlylinks, so their totals are worked out fromlinks.last.- Sort values are mapped to the names Spryker’s search configuration publishes (
rating,name_asc,name_desc,price_asc,price_desc,popularity), and the storefront default of newest first has no match and falls back to relevance. - Products are addressed by abstract SKU, so a storefront slug is resolved through
GET /url-resolverbefore the detail call. - Registered shoppers and guests use separate cart trees that are not interchangeable (
/cartswithitemsagainst/guest-cartswithguest-cart-items), line items are addressed by theirgroupKey, and a guest’s firstPOST /guest-cart-itemscreates the cart. - Registration with
POST /customersdoes not sign the shopper in: Spryker mails a registration key and issues no token until it is confirmed throughPOST /customer-confirmation.
Read from the source of misiki-in/spryker-connector at commit 0778226 of . Where the code has changed since, the code is right.
Quick start
From nothing to a Svelte Commerce storefront reading Spryker. You need Node.js and a Spryker to point it at; the storefront holds no data of its own.
Clone it, choose the connector, point it at Spryker
# 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/spryker-connector
# 3 — point it at your Spryker Glue API
echo PUBLIC_SPRYKER_API_URL=https://your-store.example.com >> .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_SPRYKER_API_URL | Yes | Base URL of your Spryker Glue storefront API. Boot fails, naming this variable, if it is missing. |
PUBLIC_SPRYKER_STORE_ID | No | The Spryker store name, sent as the Store header — DE, for example — for Dynamic Multistore. |
PUBLIC_SPRYKER_LOCALE | No | Sent as Accept-Language, such as de_DE. |
PUBLIC_SPRYKER_ANONYMOUS_CUSTOMER_ID | No | A guest identity replayed as X-Anonymous-Customer-Unique-Id. The browser mints its own; this exists for server rendering. |
PUBLIC_SPRYKER_NAVIGATION_KEY | No | The key for GET /navigations/{key}: Spryker has no route that lists navigations. |
PUBLIC_SPRYKER_ACCESS_TOKEN | No | Sent as a bearer token when set. |
PUBLIC_CONNECTOR | No | Only when more than one connector is installed: @misiki/spryker-connector names the one this build runs on. |
init.ts hands the connector every PUBLIC_SPRYKER_* variable that is set, camel-cased: PUBLIC_SPRYKER_ANONYMOUS_CUSTOMER_ID arrives as anonymousCustomerId. The guide also lists PUBLIC_SPRYKER_API_KEY, PUBLIC_SPRYKER_API_SECRET, PUBLIC_SPRYKER_ACCESS_KEY and PUBLIC_SPRYKER_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 Spryker
- Name the store in
PUBLIC_SPRYKER_STORE_IDif you run Dynamic Multistore: it travels as theStoreheader.
How the integration works
Spryker’s Glue storefront API answers in JSON:API, and the connector ships a deserialiser that resolves included relationships (the jsonapi file in its source is that helper, not a service). The store travels as a Store header, the locale as Accept-Language, and a guest as X-Anonymous-Customer-Unique-Id.
Checkout in Spryker is two calls: POST /checkout-data, which says what is still missing and which payment and shipment methods this cart can use, and POST /checkout, which places the order. Payment is chosen by method and provider names configured per store. The connector wires both as getCheckoutData() and placeOrder(); the storefront’s per-gateway methods stay placeholders, because inventing them would mean guessing a store’s payment method names.
Limitations on Spryker
- The storefront cannot place an order. Checkout counts as wired because the connector reaches Spryker’s checkout endpoints, but the storefront’s payment step calls one method per gateway — cash on delivery, Razorpay, Stripe and the rest — and on Spryker each of those is a placeholder. The connector’s
getCheckoutData()andplaceOrder()are not called by the storefront yet.
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.
Offer a sandbox or a correctionFAQ
Questions about Svelte Commerce on Spryker
Can I run a Spryker store on Svelte Commerce today?
Not to take orders. Browsing, cart and sign-in are wired, but the storefront’s payment step calls per-gateway methods that are placeholders on Spryker. The connector has the Spryker-native getCheckoutData() and placeOrder(); the storefront does not call them yet.
How do I switch Svelte Commerce to Spryker?
Remove the connectors the storefront ships with, install @misiki/spryker-connector, set PUBLIC_SPRYKER_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 Svelte Commerce place an order on Spryker?
Spryker has exactly two checkout endpoints — one to check what is missing, one to place the order — and chooses payment by names each store configures. The storefront expects one method per gateway, and inventing those would mean guessing a store’s payment method names, so the connector leaves them as placeholders.
Sources
SPRYKER.md, read on ; CONNECTORS.md, read on ; the connector’s source at 0778226. Where they disagree with this page, they are right. Spryker is a trademark of its owner, named only to describe compatibility; see trademarks.