Svelte Commerce × nopCommerce
Svelte Commerce on nopCommerce
nopCommerce core ships no REST API, so this connector targets the Web API Frontend plugin’s contract, v4.50.09 from 2022. Browsing, cart and sign-in are wired; the storefront cannot place an order on it yet.
- 24/43 services wired
- @misiki/nopcommerce-connector 0.5.0
- Cart wired
- Checkout wired
- Sign-in (auth) wired
What works on nopCommerce today
Browsing, cart and sign-in are wired, but the storefront cannot complete an order yet. nopCommerce checks out in five steps through its plugin, with payment chosen by a payment plugin’s system name. The connector wires those steps as nopCommerce-native methods, but the storefront’s payment step calls one method per gateway, and each of those throws NotSupportedError.
Cart
Wired: issues a real request to nopCommerce.
Checkout
Wired: issues a real request to nopCommerce.
Sign-in (auth)
Wired: issues a real request to nopCommerce.
Known gaps: coupon, currency
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 nopCommerce
The connector calls the paid Web API Frontend plugin under /api-frontend, an RPC-style JSON API shaped /api-frontend/{Controller}/{Action}[/{id}] and pinned to the plugin’s published OpenAPI contract v4.50.09.
POST /api-frontend/Authenticate/GetToken returns a JWT that the connector holds in its credentials and sends as Authorization: Bearer; with no token it first requests one with is_guest: true, because the token is the whole session and nopCommerce has no cart ID or cart cookie.
| Service | What it requests |
|---|---|
product | GET /api-frontend/UrlRecord/GetBySlug?slug= to turn a slug into an ID, then GET /api-frontend/Product/GetProductDetails/{id}; lists use POST /api-frontend/Catalog/GetCategoryProducts/{id} with page_number, page_size and order_by in the body |
category | GET /api-frontend/Catalog/GetCatalogRoot?loadImage=true for the tree and POST /api-frontend/Catalog/GetCategory/{id} for one category |
search | POST /api-frontend/Catalog/Search?q= with a paging command, and GET /api-frontend/Catalog/SearchTermAutoComplete?term= for suggestions |
cart | GET /api-frontend/ShoppingCart/Cart, POST /api-frontend/ShoppingCart/AddProductToCartFromCatalog/{id}?shoppingCartType=ShoppingCart&quantity= and POST /api-frontend/ShoppingCart/UpdateCart for quantity changes and removals |
checkout | GET /api-frontend/Checkout/ShippingMethod, POST Checkout/SelectShippingMethod?shippingOption=, GET Checkout/PaymentMethod, POST Checkout/SelectPaymentMethod?paymentMethod=, POST Checkout/EnterPaymentInfo and GET Checkout/ConfirmOrder |
order | GET /api-frontend/Order/CustomerOrders and GET /api-frontend/Order/Details/{id}, both scoped to the token’s customer |
auth | POST /api-frontend/Authenticate/GetToken with email and password, GET then POST /api-frontend/Customer/Register, GET /api-frontend/Customer/Info and POST /api-frontend/Customer/PasswordRecoverySend |
address | GET /api-frontend/Customer/Addresses, POST Customer/AddressAdd, PUT Customer/AddressEdit and DELETE Customer/AddressDelete/{id} |
nopCommerce rules the connector follows
- Detail routes take an integer ID, never a slug, so every slug costs a
UrlRecord/GetBySluglookup first; the connector caches the answers, misses included. - Catalogue lists are
POSTrequests with the paging in the JSON body, and the real totals are read from a nested pager block such ascatalog_products_model; routes that return a bare array are reported as one page of what came back. - Cart changes are sent as storefront form fields, such as
itemquantity{cartItemId}andremovefromcart, because the cart controller has noDELETEand removal goes throughShoppingCart/UpdateCart. - A price filter is one
pricestring in the formfrom-to, and sorting is a numericorder_byin which creation date sorts newest first only. - On a 401 the connector replaces only a guest token, never a signed-in customer’s, and a failed sign-in is not retried with the username, since each attempt counts towards the store’s lockout limit.
Read from the source of misiki-in/nopcommerce-connector at commit a847d14 of . Where the code has changed since, the code is right.
Quick start
From nothing to a Svelte Commerce storefront reading nopCommerce. You need Node.js and a nopCommerce to point it at; the storefront holds no data of its own.
Clone it, choose the connector, point it at nopCommerce
# 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/nopcommerce-connector
# 3 — point it at your nopCommerce store
echo PUBLIC_NOPCOMMERCE_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_NOPCOMMERCE_API_URL | Yes | Base URL of the nopCommerce store running the Web API Frontend plugin. Boot fails, naming this variable, if it is missing. |
PUBLIC_NOPCOMMERCE_ACCESS_TOKEN | No | A customer token to start from. Without one, the connector requests a guest token before the first cart or wishlist call. |
PUBLIC_CONNECTOR | No | Only when more than one connector is installed: @misiki/nopcommerce-connector names the one this build runs on. |
init.ts hands the connector every PUBLIC_NOPCOMMERCE_* variable that is set, camel-cased. The guide also lists PUBLIC_NOPCOMMERCE_API_KEY, PUBLIC_NOPCOMMERCE_API_SECRET, PUBLIC_NOPCOMMERCE_ACCESS_KEY, PUBLIC_NOPCOMMERCE_STORE_ID and PUBLIC_NOPCOMMERCE_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 nopCommerce
- Install nopCommerce’s Web API Framework and Web API Frontend plugins. Core ships no REST API; the connector targets the Frontend plugin’s v4.50.09 contract.
How the integration works
The connector speaks the Web API Frontend plugin’s contract (v4.50.09, 2022), not nopCommerce core, which has no REST API. A shopper who has not signed in gets a guest token before the first cart call, and tokens travel as Authorization: Bearer.
Checkout in nopCommerce is five steps — billing address, shipping method, payment method, payment info, confirm — with the payment chosen by a payment plugin’s system name, and redirect gateways finishing on the store’s own return URL. The connector wires those steps as nopCommerce-native methods; the storefront’s per-gateway methods throw NotSupportedError, because an empty answer from a checkout call reads as “payment started”.
Limitations on nopCommerce
- The storefront cannot place an order. The storefront’s payment step calls one method per gateway — cash on delivery, Razorpay, Stripe and the rest — and nopCommerce has no per-gateway route, so each throws
NotSupportedError. The connector’s nopCommerce-native checkout steps are not called by the storefront yet.
Troubleshooting nopCommerce
| When you see | What to do |
|---|---|
| Every authenticated call returns 401 | The connector sends Authorization: Bearer <token>, as the plugin’s security scheme describes; the plugin’s own curl example sends the bare token. If your store expects the bare token, set BaseService.AUTH_RAW_TOKEN = true once at startup. |
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 nopCommerce’s maintainers: If there is a published API contract newer than Web API Frontend v4.50.09, where is it?
Offer a sandbox or a correctionFAQ
Questions about Svelte Commerce on nopCommerce
Can I run a nopCommerce store on Svelte Commerce today?
Not to take orders. Browsing, cart and sign-in are wired through the Web API Frontend plugin, but the storefront’s payment step calls per-gateway methods that throw on nopCommerce. The connector wires nopCommerce’s own five-step checkout; the storefront does not call it yet.
How do I switch Svelte Commerce to nopCommerce?
Remove the connectors the storefront ships with, install @misiki/nopcommerce-connector, set PUBLIC_NOPCOMMERCE_API_URL in .env and start the dev server. vite.config.ts resolves whichever connector is installed, so no file in the storefront changes.
Does nopCommerce need a plugin for Svelte Commerce?
Yes. nopCommerce core ships no REST API, so the connector targets the Web API Frontend plugin’s contract, version 4.50.09 from 2022, which needs the Web API Framework plugin too. If a newer contract is published, the Svelte Commerce maintainers have asked to be pointed at it.
Sources
NOPCOMMERCE.md, read on ; CONNECTORS.md, read on ; the connector’s source at a847d14. Where they disagree with this page, they are right. nopCommerce is a trademark of its owner, named only to describe compatibility; see trademarks.