DEV Community: Santi

Building an AI Store Operations Agent for Creem with OpenClaw

Santi — Tue, 31 Mar 2026 19:56:42 +0000

Your Creem store generates events all day — new sales, failed payments, cancellations, upgrades, downgrades. If you're a solo founder or a small team, checking the dashboard every few hours is not sustainable. You miss things. A payment fails on Friday night, and you don't notice until Monday. A customer cancels, and by the time you react, they're gone.

This guide shows you how to build an AI agent that monitors your Creem store 24/7. It doesn't just send alerts — it analyzes situations and takes action. When someone cancels, the agent calculates their lifetime value, decides whether to offer a discount, and executes it. No human in the loop unless the agent isn't confident enough.

Architecture

The agent uses three layers, each solving a different problem:

Layer 1: Webhooks — Real-time event processing

When something happens in your Creem store, the platform fires a webhook event. Our lightweight bridge service (bridge/webhook-receiver.ts) receives it, verifies the HMAC-SHA256 signature to confirm it's authentic, deduplicates it by event ID, and logs it to events.jsonl as an audit trail.

Creem often emits multiple events for one business action — for example a single purchase can generate subscription.update, subscription.active, checkout.completed, and subscription.paid. To avoid waking the agent four times for one checkout, the bridge batches events for a few seconds and sends a single summary to OpenClaw.

Instead of using /hooks/wake, the bridge calls OpenClaw's /hooks/agent endpoint. That matters because /hooks/agent can both run an isolated agent turn and deliver the result back to the user over Telegram. The bridge also auto-detects the latest Telegram recipient from OpenClaw's session store, so after you message the bot once, future webhook alerts can be routed there automatically.

The bridge is intentionally thin — a small Bun + Hono service with no business logic of its own. It doesn't decide what to do. It just makes sure the event is real, logs it, batches noisy event bursts, and hands the situation off to the brain. If you need to audit what happened, events.jsonl has every verified event with timestamps, customer IDs, and the full raw payload.

Layer 2: CLI — Active control

The Creem CLI is how the agent interacts with your store. It can list customers, inspect subscriptions, check transaction history, create discounts, pause subscriptions, and more — all from the terminal.

This is what makes the agent more than a notification bot. When the churn analysis says "offer a 20% discount to retain this customer," the agent actually does it. It runs creem discounts create, then notifies you on Telegram with what it did and why.

The CLI uses the same Creem API you'd use from the dashboard, but it's terminal-native — which means an AI agent can use it directly. No API client libraries, no SDK, no code to maintain.

Layer 3: Heartbeat — Periodic health monitoring

Webhooks are fast, but they're not 100% reliable. Networks fail, services go down. The heartbeat is your safety net.

Every 30 minutes, OpenClaw's native heartbeat system triggers the agent to run a full store health check. The agent:

Loads the previous state from ~/.creem/heartbeat-state.json
Queries the store for current transactions, subscriptions, and customers
Compares the two snapshots
Reports any changes — or stays silent if nothing happened

This means even if a webhook gets lost, the heartbeat catches it within 30 minutes. The state file persists across restarts, so the agent never loses track of where it was.

Proactive Workflows

The agent handles all 13 Creem webhook events, but three workflows stand out:

Failed payment alerts

When a subscription goes past_due, the agent doesn't just say "payment failed." It fetches the customer's details, checks their transaction history (first-time failure vs. repeat offender), and sends you a Telegram alert with full context:

Customer email and product
Payment amount
How long they've been a subscriber
Whether this is a recurring problem

This context matters. A first-time failure on a $200/month enterprise customer deserves more attention than a repeat failure on a $5 trial.

Churn detection and autonomous retention

This is the agent's most powerful workflow. When a subscription is canceled or scheduled for cancellation:

The agent fetches the customer's full history — product, plan, country, subscription age
It calculates their lifetime value by summing all transactions
It analyzes the situation and chooses one of three actions:
- Create a retention discount — for high-value customers worth saving
- Suggest pausing — for customers who might come back later
- No action — for very new or low-value customers
If the agent's confidence is 80% or higher, it executes the action autonomously and notifies you after the fact
If confidence is below 80%, it sends you a recommendation on Telegram and waits for approval

This confidence-based execution model means the agent handles the clear cases on its own (saving you time) while escalating the ambiguous ones (keeping you in control). You get the best of both worlds: automation without blind trust.

Daily revenue digest

Every day, the agent generates a summary of your store's activity:

Total revenue for the day
Number of new transactions and customers
Subscription changes (new, canceled, upgraded, downgraded)
Active subscriber count
Comparison with the previous day

This replaces the "open the dashboard and squint at graphs" ritual. One Telegram message, every morning, with everything you need to know.

Natural Language Queries

You don't need to memorize CLI commands. Just ask the agent in plain English:

"How much revenue did we make this week?"
"How many active subscribers do we have?"
"Who cancelled today?"
"Show me the last 10 transactions"
"What products do we have?"

The agent translates your question into the right CLI commands, runs them, and gives you a human-readable answer. This works because OpenClaw agents have full access to the tools defined in their skills — the Creem CLI is just another tool.

Setup

Prerequisites

OpenClaw installed and running
Creem CLI installed and authenticated
A Creem API key (test mode recommended to start)
A Telegram bot (create one via @BotFather)
Bun runtime (for the webhook bridge)
ngrok (to expose the webhook bridge to the internet)

Step 1: Clone the repo

git clone https://github.com/santigamo/creem-openclaw-agent
cd creem-openclaw-agent

Everything lives in the repo: AGENTS.md, HEARTBEAT.md, the skill, and the webhook bridge.

Step 2: Install the skills

# Install the Creem CLI skill
npx skills add santigamo/creem-cli-developer-toolkit

# Copy the store agent skill into the OpenClaw workspace
cp -r skills/creem-store-agent ~/.openclaw/workspace/skills/

Step 3: Merge agent instructions into the workspace

Instead of blindly overwriting the workspace files, ask the agent to read the repo versions and merge them into its current workspace:

Read these two files and merge their content into your current AGENTS.md and HEARTBEAT.md.
Our content takes priority — keep any useful defaults from the current files but the
core instructions should come from ours:

~/Code/creem-openclaw-agent/AGENTS.md
~/Code/creem-openclaw-agent/HEARTBEAT.md

This preserves any useful OpenClaw defaults while applying the Creem-specific behavior.

Step 4: Enable hooks in OpenClaw

openclaw config set hooks.enabled true
openclaw config set hooks.token "your-hooks-secret"
openclaw gateway restart

Step 5: Configure the webhook bridge

cp .env.example .env

Fill in your .env:

CREEM_WEBHOOK_SECRET=your_signing_secret   # From Creem dashboard → Webhooks
OPENCLAW_HOOKS_TOKEN=your_hooks_token      # Same value used in OpenClaw hooks config
WEBHOOK_PORT=3000

Step 6: Start the bridge and tunnel

# Terminal 1: webhook bridge
pnpm install
pnpm webhook

# Terminal 2: ngrok tunnel
ngrok http 3000

https://your-ngrok-url.ngrok-free.app/api/webhooks/creem

Step 7: Enable Telegram delivery

Message your Telegram bot once. That's enough.

OpenClaw creates a Telegram session for that conversation, and the webhook bridge can auto-detect that session and route future alerts there. No manual chat ID lookup is required.

Step 8: Open the WebUI and run

openclaw dashboard

That's it. The agent starts monitoring on the next heartbeat cycle (every 30 minutes), and processes webhook events in real time.

How to Extend

The agent is built with standard OpenClaw patterns, so extending it is straightforward:

Add more notification channels — The skill can be modified to send alerts to Slack or Discord instead of (or in addition to) Telegram
Custom retention logic — Edit the churn analysis section in skills/creem-store-agent/SKILL.md to adjust confidence thresholds or add new retention strategies
Additional workflows — Add dispute handling, upgrade celebration messages, or weekly trend reports by extending the skill
Multiple stores — Run separate OpenClaw agents with different Creem API keys, each monitoring its own store

The key design principle is that the agent's behavior is defined in plain text files (SKILL.md, AGENTS.md, HEARTBEAT.md). No code to compile, no plugins to build. You edit markdown, restart the gateway, and the agent adapts.

Conclusion

An AI store operations agent is not about replacing human judgment — it's about making sure nothing falls through the cracks. Failed payments get caught immediately. Cancellations get analyzed before they're forgotten. Revenue summaries arrive without you asking.

The three-layer architecture (webhooks + CLI + heartbeat) gives you speed, control, and reliability. The confidence-based execution model gives you automation without blind trust. And because it's all built on OpenClaw skills, the entire thing is portable, shareable, and extensible.

Your store never sleeps. Now your monitoring doesn't have to either.

This agent was built for the OpenClaw + CREEM AI Agent Worker Bounty. The full source code, skills, and setup instructions are available on GitHub. Questions or feedback? Open an issue or reach out on X @imsantigamo.

Using the Creem CLI as a Developer Power Tool with Claude Code

Santi — Sat, 28 Mar 2026 13:19:32 +0000

If you build with Creem, you know the loop: write some code, open the dashboard, check if the checkout went through, check the webhook logs, compare with your local state, go back to the code. Four tabs, three data formats, five minutes just to confirm a test purchase landed. Repeat for every change.

This guide shows a different approach. You stay in the terminal. The Creem CLI provides the data, Claude Code interprets it, and your app shows the result. Everything in one place.

I built a small integration to demonstrate this. The repo includes a minimal Bun + Hono app that handles checkouts and webhooks, plus a Claude Code skill that teaches the AI how to operate the Creem CLI safely. The entire workflow — verify, debug, operate — happens from the terminal.

The setup

The integration is intentionally small. A Bun server running Hono that creates checkout sessions, receives and verifies webhook events from Creem using HMAC SHA-256, and persists local state to JSON files. The home page shows a color-coded status badge — green for access granted, red for revoked, yellow for in-progress, gray for no activity — so you can see the current state at a glance without reading JSON.

The app tracks a simple state machine: unknown → checkout-created → checkout-completed → granted → revoked. Every transition is driven by a webhook event. If the webhook doesn't arrive, the state doesn't change. This becomes important later.

The key thing to understand is that the Creem CLI and the app are two independent views of the same data. The CLI talks directly to the Creem API. The app only learns about changes through webhooks. When they agree, everything is fine. When they don't, something broke — and the CLI can help you find out what.

Teaching Claude Code the Creem CLI

Claude Code is a capable AI coding assistant, but it doesn't know how to use the Creem CLI out of the box. It doesn't know the commands, the flags, or the conventions — like the fact that Creem returns money amounts in minor units, where 500 means 5.00 EUR, not 500.00.

That's why I built a skill. In Claude Code, a skill is a structured document that teaches the AI how to use a specific tool. It covers the available commands, the correct flags, safety rules, and common workflows.

The Creem CLI skill includes:

A quick reference table for every supported command: products, customers, checkouts, subscriptions, transactions, and configuration
Rules like "always use --json for machine-readable output" and "never read or expose the config file at ~/.creem/config.json"
Money amount conventions: always convert minor units before showing values to the user
High-value workflows: how to create and verify a checkout, how to look up customers, how to manage subscription lifecycle
Automation patterns for scripting and piping output through jq

The skill lives in the repo at skills/creem-cli/SKILL.md and anyone can install it with one command:

npx skills add santigamo/creem-cli-developer-toolkit

Once installed, Claude Code loads the skill automatically when it's relevant. You talk in natural language, and it translates your intent into the correct CLI commands with the right flags and safety constraints.

Workflow 1: Verify a purchase

The first thing you want to know when building a payment integration is: does it work? Did the checkout go through? Did the webhook land? Does my app agree with the payment provider?

Normally you'd check the Creem dashboard for the transaction, then check your server logs for the webhook, then maybe hit your debug endpoint to compare. Three different places, three different formats.

With the CLI skill loaded, the conversation looks like this:

You: "Create a test checkout for my product and give me the URL."

Claude Code runs creem checkouts create --product <id> --success-url http://localhost:3000/success --json, parses the response, and hands you the checkout URL. You open it, complete the sandbox purchase with a test card, and come back.

You: "I just completed the purchase. Can you verify the transaction went through?"

Claude Code runs creem transactions list --json, finds the new transaction, and explains: paid, the amount in human-readable format (converting from minor units), the associated subscription ID. No raw JSON to read.

You: "Does the subscription look healthy?"

Claude Code runs creem subscriptions get <id> --json and confirms: active, renewal date set, everything nominal.

You: "Check my app's local state too — does it agree with Creem?"

Claude Code hits curl localhost:3000/api/debug/state, compares the local access status with what the Creem API returned, and confirms they match. The app's status badge shows green: "Access Granted."

One conversation, zero dashboard tabs. Claude Code explains the results in plain English, so you don't have to parse any JSON yourself.

Workflow 2: Diagnose a state mismatch

Verifying the happy path is useful, but the real value shows up when something breaks. Specifically: when your payment provider knows something that your app doesn't.

This happens more often than you'd think. A subscription gets paused or canceled on the Creem side, but the webhook doesn't land — maybe your endpoint was down, maybe there was a network hiccup, maybe your tunnel dropped. Your app keeps showing "Access Granted" while the subscription is actually paused. Your user has access they shouldn't have, or worse, they lost access and your app doesn't know.

Finding this kind of mismatch by hand means opening the Creem dashboard, finding the subscription, checking its status, then comparing with your database or local state, then checking your webhook logs to see if the event was ever delivered.

Here's how it looks with the CLI:

You: "Pause the subscription from my last test purchase, then compare what Creem says with what my app says. I want to know if subscription changes are propagating correctly."

Claude Code runs the pause command, then gathers evidence from both sides: creem subscriptions get <id> --json and creem transactions list --json for the Creem state, and curl localhost:3000/api/debug/state for the app state. It compares them and reports the finding.

In my test, the result was clear: Creem shows the subscription as paused, but the app still says "Access Granted." The status badge on the home page is still green. The webhook never arrived.

Claude Code didn't just find the mismatch — it explained why. The subscription changed in Creem, Creem tried to send a webhook, but the endpoint wasn't reachable. The local state is stale.

You: "What are my recovery options?"

Claude Code suggests concrete steps: restore the webhook endpoint, then either replay the event if the platform supports it, or trigger another state change so the next webhook lands and syncs the state. It adapts the suggestions to what it knows about the setup.

The same investigation through dashboards and logs — opening the subscription page, cross-referencing with webhook delivery logs, checking your server output — would involve a lot more clicking and context-switching. Here it was one prompt and a clear answer.

Workflow 3: Operate the store

The CLI isn't just for testing and debugging. Once you're comfortable with it, you can manage your Creem store without leaving the terminal.

First, recovery from the previous workflow. After restoring the webhook endpoint:

You: "My endpoint is healthy again. Resume that subscription and confirm the current state."

Claude Code resumes the subscription, verifies the state on both sides, and confirms everything is back in sync. The app's status badge flips back to green, and the webhook event shows up in the recent events table.

Then, product management:

You: "I want to add a Pro Plan to my store. 19 dollars a month, recurring."

Claude Code runs creem products create with the right flags: --name "Pro Plan", --price 1900 (minor units), --currency USD, --billing-type recurring, --billing-period every-month. One sentence from you, one command from the CLI.

You: "List all my products to confirm."

Claude Code runs creem products list --json and shows you both products — the original test product and the new Pro Plan.

You: "Give me a summary of the current state of my store."

Claude Code pulls products and subscriptions, cross-references them, and gives you a plain English overview: how many products, how many active subscriptions, current revenue state. The kind of snapshot that would normally require opening the dashboard and clicking through several pages.

Why this matters

The pattern here isn't specific to Creem. It's what happens when a CLI tool produces structured JSON output and an AI assistant knows how to read it. The skill bridges the gap — it teaches the AI the commands, the conventions, and the guardrails. Together, they turn a series of manual dashboard checks into a conversation.

If you've ever spent fifteen minutes bouncing between a payment dashboard, your server logs, and a database query just to confirm a webhook landed, this is the alternative. One terminal, one conversation, same answer.

Try it yourself

The repo is open and includes everything you need:

A minimal Bun + Hono app with checkout, webhook, and state tracking
The Claude Code skill for the Creem CLI
Setup instructions and environment configuration

Install the skill:

npx skills add santigamo/creem-cli-developer-toolkit

Clone the repo, set up your Creem test credentials, start the app, and start talking to Claude Code. The skill handles the rest.

GitHub: santigamo/creem-cli-developer-toolkit