Headless Commerce Orchestration · for MintJams CMS

Inventory, orders, refunds.
Run them automatically,
and only when needed,
quietly hand them to people.

MintJams Commerce receives Shopify webhooks, normalizes them into the repository, and processes them with BPMN workflows — a headless commerce orchestration layer. Only the inventory that dips below threshold, the orders that need review, and the refunds you want to audit are turned into operator tasks and notifications. Bundled in the same Docker image as MintJams CMS; all that's left is configuration.

Run with Docker View on GitHub →
✓ MIT License ✓ Bundled in cms0 ✓ Shopify integration
⌁ localhost:8080/desktop
⋯
MintJams virtual desktop — inventory review workflow with BPMN Modeler, Tasks, and BPM Console
⌁ localhost:8080/desktop
⋯
MintJams virtual desktop — Shopify data integration with EIP Modeler and EIP Console
⌁ localhost:8080/desktop
⋯
MintJams virtual desktop — Commerce Dashboard KPI cards and storefront preview
Webhook verified HMAC-SHA256
Manual Inventory Check · unassigned
Built on open standards and proven implementations
Docker
Shopify Webhooks
BPMN 2.0
EIP Routes
JCR 2.0
GraphQL Admin API
How it works

One path, and everything flows through it.

Events from Shopify are verified, normalized, put on a workflow, and routed to people only when needed. From intake to notification, it runs as one continuous pipeline.

SHOPIFY

Event occurs

Product updates, order confirmations, refunds, and more. A webhook fires.

ENDPOINT

Receive & verify signature

A Groovy endpoint verifies with HMAC-SHA256.

EIP ROUTE

Intake & normalize

Into the shared intake core. The raw payload is stored.

JCR

Store as current state

Into a repository with versioning, full-text search, and ACLs.

BPMN

Workflow decision

Evaluate thresholds and screening. Automatic, or human.

HUMAN + NOTIFY

Human task & notify

File a task for the operator and notify each channel.

Every topic captured as a first-class event Failures get bounded automatic retries + manual replay Duplicate workflows on the same target are blocked by a re-entry guard
Platform

Receive, run, notify.
The three beats of operations, on one foundation.

Connecting to external commerce, business processes, and handing off to people. The mechanisms that used to be separate are brought together on the same MintJams CMS desktop.

Receive — event intake

Every topic into a single intake core. Raw payloads are stored and can be reprocessed at any time.

  • Signature-verified webhook intake (HMAC-SHA256)
  • Multi-backend ready — throw the same envelope and downstream stays unchanged
  • Event log & replay (reprocessing, not duplication)

Run — business workflows

BPMN 2.0 processes decide on inventory, orders, and refunds. Anything that doesn't hit a rule passes through automatically.

  • Inventory alerts / order review / refund review
  • Configurable screening (fail-open, safely approving by default)
  • Live monitoring and instant deploy with BPM Console and BPMN Modeler

Notify — human tasks & notifications

Only when a decision is needed does it become an operator task. We track who picked it up and notify each channel.

  • Claim / assign to the team / complete in the Tasks app
  • Slack, Discord, Teams, LINE, Email, generic Webhook
  • Best-effort delivery — a failed notification never stops operations
01 — Inventory alert tool

When stock dips,
hand it to a person.

When Shopify inventory falls below the per-variant threshold, a manual review task is filed and the configured channels are notified. Not a fire-and-forget alert — we track who takes the follow-up.

01
Threshold setup task

For a product seen for the first time, the operator decides — per variant — the count at which to warn.

02
Manual Inventory Check

Detects a stock dip and files a task. The operator reviews the situation and marks it handled.

03
Re-entry guard

Prevents a product already in progress from starting a duplicate workflow. The latest data keeps being stored, so nothing slips through.

⌁ localhost:8080/desktop
⋯
Screenshot of the inventory review workflow with Tasks, BPMN Modeler, and BPM Console
02 — Shopify data integration & replay

Run your integrations
in a form you can see.

Intake is designed and deployed as EIP routes. Because raw payloads are kept in a durable event log, failed events are retried automatically and any event can be replayed manually. Write-backs are gated through the Admin API.

01
A source-agnostic intake core

The only Shopify-specific part is a small topic→route table. A new backend is just an added adapter.

02
Live monitoring with EIP Console

Visualize success / error / latency per route with exchange history and metrics. Bottlenecks at a glance.

03
Two-way sync (CMS → Shopify)

Write inventory, price, and publish state back via the Admin API. Safely, with dryRun and an audit trail.

⌁ localhost:8080/desktop
⋯
Screenshot of Shopify integration routes and exchange history with EIP Modeler and EIP Console
03 — Operations monitoring & dashboard

The platform itself
keeps watch over itself.

Outside the business workflows, it observes webhook intake, route processing, and Admin API calls. It bundles KPIs into one screen and, when it detects degradation or backlog, alerts the same notification channels.

01
Commerce Dashboard

Real-time, read-only KPI cards covering sales, inventory, forecasts, purchasing, tasks, and integration health.

02
Integration Health Monitor

Observes success / error / latency by topic and alerts on degradation.

03
Task SLA Monitor

Periodically scans for stalled review tasks and escalates — raising priority and notifying.

⌁ localhost:8080/desktop
⋯
Commerce Dashboard — KPI cards for sales, inventory, forecasts, and integration health
04 — Configuration & notifications

Configure on screen,
save as YAML.

Every setting lives in the admin-only Commerce app. Edit through a grouped sidebar — Connection / Intake & sync / Inventory / Workflows / Storefront / Monitoring — and persist it all with a single Save. Connection details and notification targets are kept in separate files, so you can manage destinations without touching API secrets.

01
Grouped configuration

Each section carries an unsaved marker and applies together with one Save.

02
Six-plus notification channels

Enable Slack, Discord, Teams, LINE, Email, and a generic Webhook independently.

03
Secrets separated from notifications

Manage notifications.yml and shopify.yml separately. Delegate operations safely.

⌁ localhost:8080/desktop
⋯
Screenshot of the Commerce settings console — grouped sidebar and notification channel configuration
05 — PIM / data platform

Enrich product data
with CMS-side overlays.

Add multilingual titles, rich descriptions, custom attributes, and metafields to Shopify products as a CMS-authoritative overlay. Because they're stored on the product node, they inherit JCR versioning, full-text search, and ACLs directly. Edit in a unified view that composes the Shopify base + metafields + overlay, and write CMS-originated metafields back through the sync endpoint.

01
Localized content

Craft locale-specific titles and HTML descriptions per product.

02
Versioned overlay

Stored on the product node, inheriting history, full-text search, and ACLs. Edit safely.

03
Onward to reconciliation & reporting

The same mirror also becomes the basis for drift reconciliation and sales / audit exports.

⌁ localhost:8080/desktop
⋯
Screenshot of Commerce PIM — editing localized product content with the resulting storefront preview
Feature modules

This much is in place from day one.

Each feature can be configured independently and degrades gracefully when no input is given. Adopt only as much as you need.

Inventory alerts

Detects a threshold dip and files / notifies a Manual Inventory Check.

Order review

Screens high-value, risky-payment, and high-quantity orders, routing only those needing review to people.

Refund review

Audit / fraud monitoring that moves no money. Also updates the order's refund summary.

Inventory intelligence

Stay ahead of stockouts with dynamic thresholds, demand forecasting, and auto-purchasing.

Backorders

Tracks line-level waits in FIFO and files a release task when stock arrives.

PIM

Overlay multilingual titles, descriptions, and metafields with versioning.

Reconciliation

Periodically compares the CMS mirror with Shopify. Detects, reports, and self-heals drift.

Reporting & audit exports

Sales and write-back audits in JSON / CSV. Generated from the JCR trail.

Customer CRM

Classifies as new / repeat / vip / at_risk / dormant from purchase history.

Commerce Dashboard

Read-only KPIs bundling sales, inventory, forecasts, and integration health.

Integration Health

Observes intake, processing, and API calls, alerting on degradation.

New backends, too

Rakuten / BASE / in-house commerce / ERP. Just add an adapter that throws the same envelope.

Background

Why an "orchestration layer"?

Automate e-commerce operations entirely and you fear what slips through. Do it all by hand and it doesn't scale. MintJams Commerce was born to make that boundary designable.

Before

Automation, or manual work

  • Alerts fire, but you can't track who handled them
  • Decision rules for inventory, orders, and refunds scattered across scripts
  • When an integration goes down, you find out only when a customer asks
  • Change the backend and you rebuild the entire plumbing
With MintJams Commerce

Run it automatically, hand it to people only when needed

  • Turn into a task only the moment a decision is needed, and track it to the operator
  • Screening is YAML config. Fail-open, safely approving by default
  • Monitor and alert on intake, processing, and APIs from a shared dashboard
  • The intake core is source-agnostic. A new backend is just an adapter
Identity & access

It does not run as admin.

Integration processing runs not as an unrestricted superuser but as an ordinary principal that follows the repository ACLs, granted its own dedicated identity, groups, and ACLs on first launch. Writes are only appended to paths the platform owns.

SU
commerce-service-user
A service account that cannot sign in. The non-interactive principal that runs EIP routes and BPMN service tasks via runAs.
G
commerce-service-group
The group bundling the write permissions the service user needs.
OP
commerce-operators
Delegates commerce administration to non-admin operations staff. Add real operators from Identity Manager.
Quickstart

If Docker runs,
it's already bundled.

There is no Commerce-only image. The assets are bundled in the mintjams/cms image. Start the CMS and the Commerce tools come up with it.

  • 01
    Start the CMS container

    The Commerce assets are bundled in the same image. No extra install needed.

  • 02
    Open it in your browser

    Go to http://localhost:8080 and sign in as admin.

  • 03
    Open the Commerce app

    Open Commerce from the Webtop menu and configure the integration.

  • 04
    Configure shopify.yml

    Register the webhook shared secret. Enable the Admin API optionally.

bash — run MintJams CMS (Commerce bundled) 
docker run --rm \
  -p 8080:8080 \
  -e CMS_PUBLIC_BASE_URL=http://localhost:8080 \
  -v cms-repository:/data/repository \
  -v cms-secrets:/data/secrets \
  --tmpfs /opt/felix/tmp:size=512m,mode=0700 \
  mintjams/cms:latest

# → Open http://localhost:8080/ and sign in as admin
# → Open "Commerce" from the Webtop menu and configure
commerce · bundled in mintjams/cms ● ready

From Shopify, and beyond.

The intake core doesn't know about Shopify. All it knows is a small topic→route table. For a new backend, just add an adapter that throws the same envelope (event_source / event_topic / event_id + payload) to the core, and downstream keeps working as-is.

  • Rakuten / BASE / in-house commerce / ERP — connect with a single adapter
  • Consolidate reusable logic in a shared Groovy class layer
  • Add your own notification channels and business processes, too
// backend adapters
Shopify
Rakuten
BASE
ERP
↓   throw the same envelope   ↓
⌁
direct:commerce-ingest

A source-agnostic intake core — downstream workflows stay unchanged

FAQ

Frequently asked questions

Can I use backends other than Shopify?
Yes. The intake core direct:commerce-ingest is source-agnostic. Add an adapter that throws the same envelope — event_source / event_topic / event_id + payload — and you can connect Rakuten, BASE, in-house commerce, ERP, and more with no downstream changes. The implementation bundled today is Shopify.
Does it need a separate install to set up?
No. The Commerce assets are pre-deployed in the same mintjams/cms Docker image as cms0. Start the CMS and the Commerce tools come up with it — all that's left is configuration.
Does it run with admin privileges?
No. The integration runs as a dedicated, non-interactive principal called commerce-service-user and fully obeys the repository ACLs. Writes are only appended to paths the platform owns, such as /content/commerce.
Where can it send notifications?
Slack, Discord, Microsoft Teams, LINE, Email (SMTP), and a generic Webhook are supported. Each task composes a single message and delivers it to every enabled channel in that channel's format. Delivery is best-effort; a failure never stops the business process.
Is the Shopify Admin API required?
The webhook signature-verification secret is required, but the Admin API is optional. Enable it and product webhooks get metafield enrichment, and completed Fulfill Order tasks are written back to Shopify. Disable it and no Admin API calls are made at all.
What about the license?
It's the MIT License. The source is github.com/mintjamsinc/commerce, the runtime foundation is cms0, and the UI framework is ichigo.js. Note that this product is in public preview, and APIs and configuration keys may change before 1.0.
Quickstart

Bring e-commerce operations,
and human judgment, to the desktop.

With a single Docker command, Shopify integration and business workflows are already in your hands.

Run with Docker View on GitHub →
docker run mintjams/cms:latest · MIT License · public preview