Connectors

How one storefront talks to 26 commerce backends

One shared service interface, 26 implementations, and two rules we adopted after shipping the bugs that taught them.

Svelte Commerce runs on 26 different commerce backends without the storefront code knowing which one is behind it. This is how that works, and what it costs.

The shape

A connector is a set of services extending a shared BaseService. Every connector implements the same method names with the same signatures, because the storefront calls them interchangeably. The Litekart connector is the reference — every other connector is written by reading litekart-connector/src/services/<same-file>.ts and matching it exactly.

The storefront imports from one place:

import { CartService, ProductService } from '$lib/core/services'

and one file decides what that resolves to:

// kitcommerce.config.ts
export * as services from '@misiki/vendure-connector'

Coverage is a number, not a checkmark

Each connector is scored as services wired to a real endpoint out of the storefront's service surface. The spread is wide and it is published rather than smoothed over:

PlatformCoverageNote
Vendure39/43GraphQL Shop API covers nearly everything
Litekart39/43Reference implementation
Medusa31/43Store API, COD checkout completes
WooCommerce27/43Auth throws — no core session endpoint
Shopify16/27Smaller targeted surface
OpenCart9/43Core API is admin, not storefront

Shopify is scored out of 27 rather than 43 on purpose: several storefront services have no equivalent in the API surface that connector targets, so counting them as failures would misrepresent it. At 16 of 27 its proportional coverage is comparable to a mid-tier 43-service connector.

Two rules, both learned the hard way

Never fabricate pagination totals. Read them from the platform's real envelope or headers. An invented total produces a pager that goes to page 12 of a 4-page result set.

Never return an unscoped list where the storefront expects "mine". A GET /orders without a customer filter returns every order in the store to whoever holds the key. OpenCart made this concrete: its api/order/info has no ownership check at all, so the connector quarantines it behind an admin-only method where a shopper-facing call can never reach it.

Where honesty beats coverage

When a platform has no endpoint for something, the connector leaves a documented placeholder and says why in a comment. An honest placeholder always beats a plausible path, because the plausible path fails as a runtime 404 in somebody's live shop.

Three platforms throw on auth rather than mint a session they cannot verify: WooCommerce, PrestaShop and CS-Cart. That is a lower score and a better storefront.

What it costs

Two things, and both are real.

First, an override layer. Connectors written against non-Litekart backends still call Litekart REST endpoints for store identity and CMS pages, and a store-lookup failure is fatal. Medusa, Saleor and Vendure each resolve through an override module that re-exports the connector and serves those bits from static config. Any backend you wire yourself may need the same.

Second, honest verification status. Every connector was written against its platform's authoritative contract and type-checks against it. They have not all been run against live production stores. That is published per platform in the capability matrix, along with the open questions we would like platform maintainers to answer.

Try it against your own backend.