Spryker vs commercetools: Suite Modularity vs API Product

Spryker and commercetools split on licence and code access, not deployment location

Most comparisons ask “who hosts this?” and stop there. That question doesn’t separate these two vendors: Spryker’s Cloud Commerce OS (opens in a new tab), the default commercial deployment Spryker calls “PaaS+”, is vendor-operated — Spryker states it manages infrastructure and operations on AWS so your team works at the application layer, not the infrastructure layer. commercetools is a closed-source, multi-tenant SaaS product that commercetools itself describes (opens in a new tab) as running on both Google Cloud Platform and AWS, with no customer- or partner-operated self-hosting option at any tier.

Both vendors run the servers by default. The split that actually matters is code access: Spryker publishes more than 750 independently versioned modules as source-available code across its GitHub organisations, while commercetools distributes no source code at all, at any price point.

quadrantChart
title Deployment operator vs code access
x-axis Vendor operates infra --> Customer operates infra
y-axis No code access --> Source-available code
quadrant-1 Self-hosted and open
quadrant-2 Vendor-run and open
quadrant-3 Vendor-run and closed
quadrant-4 Self-hosted and closed
Spryker Cloud Commerce OS: [0.2, 0.75]
commercetools SaaS: [0.15, 0.05]

That access isn’t unconditional. Spryker’s published code carries only a 45-calendar-day, non-production evaluation licence — production deployment, even if you run it yourself, requires a separate signed commercial agreement. The next section covers exactly what that licence permits and where teams get caught out.

Treat this as the first filter in any shortlist: which vendor operates the infrastructure, and which one grants you any code access at all. Everything else in this comparison — stack, API limits, MCP tooling, pricing — sits downstream of that split.

You should now see: which vendor operates the infrastructure, and which one gives you any code access at all, before you compare a single feature.

What Spryker’s 45-day evaluation licence actually permits

This is the fact a legal or finance reviewer checks first, so get it right before anyone else finds the gap. Spryker publishes 750+ independently versioned modules across the spryker and spryker-shop GitHub organisations, including the full Demo Shop. Every one of those repositories ships with the same bundled licence.

That licence (opens in a new tab) grants a 45-calendar-day, non-transferable evaluation right, for internal, non-production testing only. It does not cover production traffic in any form. Deploying the code — self-hosted or on Spryker’s own Cloud Commerce OS — for real customers requires a separate, signed commercial licence agreement with Spryker; the evaluation licence does not upgrade itself just because traffic goes live.

The pitfall this catches teams on: a demo shop deployment quietly starts serving real orders past day 45, and a finance or legal reviewer finds it months later with no commercial agreement on file. The fix is procedural, not technical — track the clock from the day you clone, not the day you go live, and start the commercial conversation with Spryker well before day 45.

CLONE_DATE="2026-07-28"
DEADLINE=$(date -d "$CLONE_DATE +45 days" +%Y-%m-%d)
echo "Evaluation licence for clone dated $CLONE_DATE expires: $DEADLINE"

flowchart LR
    A[Clone spryker-shop repo] --> B["Day 0: evaluation licence starts"]
    B --> C{"Signed commercial\nagreement in place\nbefore day 45?"}
    C -->|Yes| D[Production deployment permitted]
    C -->|No| E[Deployment is unlicensed]

Run the script against your actual clone date and put the resulting deadline on a calendar reminder two weeks ahead of it, not on the deadline itself — a signed commercial agreement takes longer to negotiate than a demo takes to go live.

You should now see: exactly what the free Spryker licence permits, and how to catch an unlicensed deployment before a reviewer does.

Spryker versions on a date-based release train; commercetools has no platform version at all

Spryker versions its entire suite under one date-based release train: the current one is 202606.0 (opens in a new tab), with documentation last updated 2026-07-07, covering all 750+ modules under a single scheme. That gives you one number to cite for the whole platform, even though the modules underneath it version independently.

Spryker’s supported stack (opens in a new tab) as of this release train: PHP 8.3+ (opens in a new tab) required since 2025-08 (Symfony 6.4 itself only needs PHP 8.2 as a floor), Symfony 6.4 LTS with 5.4 still supported, Propel2 as the ORM, RabbitMQ for queueing, Redis or Valkey for cache, and Elasticsearch for search.

commercetools has none of that to cite, because it has no platform version number at all — it’s continuously deployed SaaS, not a versioned release you install. What it publishes instead is a dated, per-change API release note (opens in a new tab) for every shipped change: cart locking landed 2026-01-16, reference expansion in API Extensions landed 2026-03-12. Cite the change and its date, not a version that doesn’t exist.

One of those dated changes is a breaking one: commercetools removed the unsupported GraphQL Set scalar from its schema on 2026-06-02, replacing every affected field with a standard list type. Any GraphQL client still built against the old scalar starts failing schema validation the moment that field is touched — regenerate your introspection and update the affected field types before you rely on that part of the schema again.

Spryker fact citation:
  release train 202606.0 (docs updated 2026-07-07)
  docs.spryker.com/docs/about/all/releases/release-notes-202606.0.html

commercetools fact citation:
  dated API release note, e.g. "cart locking, 2026-01-16"
  docs.commercetools.com/api/releases
  — never "commercetools vX" — no such version exists

You should now see: how to date-stamp a claim about either platform correctly, and why commercetools has no version number to reach for.

Integration surface: Spryker’s Glue REST migration vs commercetools’ hard API limits

Spryker is mid-migration on its integration layer: its internal Glue REST API infrastructure is moving to a new foundation it calls “API Platform (opens in a new tab)”. Spryker describes the move as backward-compatible and incremental, module by module, with the old Glue REST stack and the new API Platform stack running side by side during the transition.

That side-by-side period is where integrations break. A client built against a Glue REST endpoint keeps working right up until its module migrates — then it starts returning deprecation-warning headers, and later stops working once that module’s transition window closes.

sequenceDiagram
    participant Client as Integration client
    participant Glue as Glue REST endpoint
    Client->>Glue: Request (works normally)
    Note over Glue: Module migrates to API Platform
    Glue-->>Client: Response + deprecation-warning header
    Note over Glue: Transition window closes
    Client->>Glue: Request
    Glue--xClient: Endpoint retired

Check a module’s migration status before you build a client against it; this research pass could not confirm endpoint-specific retirement dates, so confirm the timeline directly with Spryker.

commercetools takes a different shape of constraint. Its HTTP API limits (opens in a new tab) are resource- and structure-based rather than a simple requests-per-second throttle — you can send requests all day and still get rejected for shape, not rate.

spryker:
  glue_rest_status: "migrating to API Platform, per-module"
  compatibility_during_transition: "old and new stacks run side by side"
  action: "confirm this module's migration status before building against it"
commercetools:
  max_document_size_mb: 16
  max_list_query_results: 500
  max_product_search_results: 100
  max_pagination_offset: 10000
  graphql_max_reference_expansion_depth: 3
  graphql_query_rejected_at_complexity: 20000

A moderately nested product query — a cart with line items, each expanding a product, each expanding a category — can stack past that 20,000 complexity ceiling and fail with QueryComplexityLimitExceeded, even though nothing about it looks unusual. Split it into multiple calls, or use the REST API’s expand parameter with fewer levels, instead of one large GraphQL query.

You should now see: the specific ceiling that will break an integration on each platform, before you write a client against either one.

AI and agent tooling: commercetools ships two MCP servers, Spryker’s Commerce MCP scope

commercetools ships two official MCP (Model Context Protocol) servers (opens in a new tab), documented and confirmed. Commerce MCP (opens in a new tab) is a project-scoped agent interface over carts, orders, products and pricing, available as either a managed or a self-hosted deployment. Knowledge MCP is free and credential-free, exposing documentation and API-schema search to IDEs including Cursor, GitHub Copilot, VS Code and JetBrains.

That free tier has a limit worth knowing before you rely on it mid-session: Knowledge MCP enforces 100 requests per 15 minutes per IP, separate from Commerce MCP’s own metering and separate again from the core REST/GraphQL API limits. An engineer running a heavy documentation-lookup session can hit 429 Too Many Requests well before touching any commerce data. Cache lookups locally during heavy sessions, or self-host Knowledge MCP if the shared limit blocks a team’s workflow.

Spryker’s picture is split between confirmed and unconfirmed. Its AI Dev SDK (opens in a new tab) documents its own MCP server for development-time assistance, adding what Spryker calls “Spryker-context awareness” to tools including a Claude Code plugin, a CLI and an LSP integration — that part is confirmed and specific.

Separately, Spryker lists a “Commerce MCP Server (opens in a new tab)” under its AI Commerce feature set, alongside Smart PIM, Smart CMS and a Back Office Assistant. This research pass could not confirm that server’s operations list or its GA-versus-beta status from the fetched documentation. The honest label is “scope not found,” not “doesn’t exist” — verify directly with Spryker before assuming either absence or parity with commercetools’ Commerce MCP.

You should now see: commercetools’ two MCP servers precisely, and exactly what to verify with Spryker before assuming its Commerce MCP Server matches them.

Neither vendor prices publicly, and they don’t meter the same thing

Neither vendor publishes a list price on its public site. That alone rules out any dollar-figure comparison drawn from a blog post or an aggregator’s “pricing calculator” — every number you find outside a vendor quote is someone else’s estimate.

commercetools describes its own model as “order-based (opens in a new tab)” rather than tied to gross merchandise value, and its pricing page directs prospects to contact sales for actual plans. That’s a metering unit, not a number — useful for structuring a quote request, not for budgeting without one.

There’s a second wrinkle worth knowing before a quote comes back: commercetools Foundry (opens in a new tab), launched 2024-01-15, is a separate pre-composed accelerator line — first B2C retail, later B2B manufacturing — built on top of the composable APIs. It sits outside core Composable Commerce’s order/quota-based pricing, so a Foundry quote and a core Composable Commerce quote aren’t the same product at different prices; they’re different products.

The pitfall here is a budget approved against a third-party figure, followed by a real quote structured on a completely different dimension — a GMV band instead of an order/projection quota, or vice versa. Request quotes from both vendors against the same order-volume and catalogue-size assumptions, and confirm explicitly whether a commercetools quote covers core Composable Commerce or Foundry before it goes into a budget line.

You should now see: the only two public pricing facts that exist for this comparison, and how to avoid mistaking a Foundry quote for a core Composable Commerce one.

Decision framework: labelled comparison table and best-for/avoid-when per platform

Every row below uses matching editions, dates and units for both platforms, so nothing here compares a Spryker fact from one year against a commercetools fact from another.

flowchart TD
    A{"Need to read or fork\nplatform source code?"}
    A -->|Yes| B{"PHP/Symfony team,\ncan sign a\ncommercial agreement?"}
    A -->|No| C{"Need self-hosting or\non-prem at any tier?"}
    B -->|Yes| D[Spryker]
    B -->|No| E[Neither fits cleanly — revisit requirements]
    C -->|Yes| E
    C -->|No| F[commercetools]

Spryker fits an enterprise that wants to read, extend or fork actual platform code during evaluation, already runs PHP/Symfony engineering teams, and is comfortable assembling a suite from 750+ modules under a single vendor relationship.

Avoid Spryker when the team can’t commit to a signed commercial agreement before the 45-day evaluation clock runs out, or when the project needs a documented, ready-made agent/MCP commerce layer confirmed today rather than pending clarification from Spryker.

commercetools fits an enterprise standardised on an API-first, assemble-your-own-frontend approach, that wants confirmed dual MCP tooling — Commerce MCP and Knowledge MCP — and treats GraphQL and REST limits as design constraints from day one rather than surprises in week three.

Avoid commercetools when the organisation needs any self-hosting or on-premises option, or needs to read the underlying platform source for compliance or customisation reasons — neither exists at any tier commercetools sells.

You should now see: enough in the table and the four statements above to match your own organisation against a platform and reach a defensible shortlist decision.

What this comparison didn’t verify

No hands-on Spryker deployment — Cloud Commerce OS or self-hosted — and no commercetools project were built or load-tested for this research pass. Every claim above comes from vendor documentation, not operational proof, and should be treated that way until someone runs it.

Spryker’s Commerce MCP Server operations list and its GA-versus-beta status weren’t confirmed. Verify directly with Spryker before assuming it matches commercetools’ Commerce MCP in scope or maturity.

Whether Spryker’s API Platform migration is complete for any specific module — or still running the legacy Glue REST stack — wasn’t checked module by module in this pass. Check that module’s own release notes before building an integration against it.

Neither vendor’s actual contract pricing was obtained. Every pricing statement here is a public positioning statement — order-based versus undisclosed — not a quote, and shouldn’t be treated as one.

Feature parity between Spryker’s suite modules and commercetools’ API primitives for any specific business capability — subscriptions, B2B quoting, and similar — wasn’t tested directly and shouldn’t be assumed equivalent without checking that capability specifically.

You should now see: exactly which claims here to re-verify with a vendor conversation or a hands-on evaluation before making a final purchasing decision.