Compatibility‑First Headless

FlxWoo vs. Store API vs. CoCart vs. Faust.js – Renderer‑Only Headless that Keeps Woo Plugins Working

Next.js renders, WooCommerce computes. A compatibility‑first approach to headless checkout that keeps your existing plugins firing through WC()→cart and WC_Checkout.

Updated Sep 20, 2025

TL;DR (Positioning in 5 lines)

What “renderer‑only” means (and why it’s fast to ship)

One brain (Woo): Totals, taxes, discounts, shipping, payments — all run via native Woo classes and hooks.

One thin BFF (Next.js): Edge middleware issues a guest session, forwards auth, enforces idempotency, and calls your FlxWoo plugin REST endpoints.

One predictable contract: Simple REST for /cart, /cart/totals, /checkout/* — no re‑inventing Woo logic.

Result: Agencies keep their plugin stack; you ship headless UX without rewriting the business rules.

FlxWoo (renderer‑only headless)

  • • Compute stays in Woo via WC()→cart / WC_Checkout.
  • • Next.js renders & acts as a BFF/proxy; no logic duplication.
  • • Best for stores with revenue depending on existing extensions.

Store API / Blocks

  • • Official modern API powering Checkout Blocks.
  • • Compatibility depends on each extension’s Blocks support.
  • • Best for greenfield builds aligned with Block‑ready plugins.

CoCart

  • • Headless‑first REST layer for Woo; mirrors many behaviors.
  • • You adapt to CoCart’s surface; FlxWoo calls Woo directly.
  • • Best for teams committing to a third‑party API product.

Faust.js

  • • Headless WP routing/preview/auth for Next.js content sites.
  • • Not a checkout engine — pair with another Woo API option.
  • • Best for editorial/CMS‑heavy experiences.

Architecture at a glance

  1. Next.js (Edge): sets flx_sess, forwards X-Cart-Session + Authorization, enforces Idempotency-Key.
  2. Next.js (BFF): calls WP endpoints: /flx/v1/introspect, /cart, /cart/totals, /checkout/*.
  3. FlxWoo WP Plugin: uses Woo objects directly (add/update/remove, calculate_totals, checkout/order).
  4. Plugins keep hooking: taxes, shipping, discounts, subscriptions, gateways continue to work.

What you keep

  • • Extension behavior via original Woo hooks.
  • • Back‑office flows (orders, refunds, emails).
  • • Predictable upgrades — no forked logic.

What you trade

  • • Absolute API purity for compatibility & delivery speed.
  • • Some calls traverse WordPress (optimize via BFF + caching).
  • • Careful Next.js design (idempotency, retries, timeouts).

When to choose which

SituationFlxWooStore APICoCartFaust.js
Heavy plugin reliance (tax/shipping/coupons/gateways)✅❓ depends on Blocks✅➖
Fastest path to modern UX without losing plugins✅❓✅➖
Greenfield build with Blocks‑ready stack❓✅❓➖
Editorial routing/preview for content‑heavy site❓❓❓✅ (+ pair another Woo API)
Team willing to adopt a third‑party API layer❓❓✅❓

Migration path (keep risk low)

  1. Start with Cart + Totals in renderer‑only mode.
  2. Add Shipping discovery and Payment intent for your PSP of choice.
  3. Wire Checkout authorize/capture, lock priced versions, create orders.
  4. Incrementally replace pages with Next.js (cart → checkout → product → category).
  5. Optional: introduce GraphQL + caching on top of your stable REST contract.

FAQ

Does this replace Store API or CoCart?
No. It’s a different trade‑off: FlxWoo prioritizes compatibility today by executing Woo’s native engine via your own plugin endpoints.

Will SEO suffer?
No. Next.js renders UI (SSR/ISR) as usual. You’re only delegating commerce compute to Woo.

What about performance?
Use a thin BFF with keep‑alive, short timeouts, idempotency, and cache hot paths (e.g., totals by cart_hash+context). You can still run Edge middleware and CDN caching for static/ISR pages.

Can I mix approaches?
Yes. Many teams keep FlxWoo for checkout and try Store API for PDP/PLP experimentation.

Try the renderer‑only headless checkout

Keep your plugins. Upgrade your UX. Zero rewrite of business logic.

Join the waitlistTalk to us