DEV Community: Roman Shalabanov

0x10 Lessons from Building with OpenClaw and What It Says About the Future of Work

Roman Shalabanov — Mon, 20 Apr 2026 09:56:48 +0000

This is a submission for the OpenClaw Writing Challenge

There's a particular kind of quiet that happens at 1 AM when a side project finally clicks.

The terminal is scrolling. The model is thinking. And then something works. Not "works with three caveats and a prayer." Just... works.

That moment hit me while building a Laravel agent integrated with Openclaw. If you haven't come across Openclaw yet: it's an AI assistant that can reason, plan, and build its own tools on the fly. Not in a marketing-deck way. In a "hold on, it just wrote a curl command, executed it, and used the result" kind of way.

The hype around it has calmed down a little, which honestly is when things get interesting. Less noise, more actual building.

What I built was a Laravel agent as an intelligent wrapper over a SaaS payment API, tracking subscriptions, products, transactions, surfacing anomalies. A kind of always-on co-pilot for a store.

But this article isn't really about what I built. It's about what building it taught me.

I've organized these lessons in hexadecimal.

That choice wasn't aesthetic alone.

Hex feels natural when you're close to systems: memory, offsets, low-level boundaries. It also forces a slightly uncomfortable shift in perception. You stop thinking in a linear "1, 2, 3…" and start thinking in a space where structure is more compact, less human-readable at first glance.

And if you read until the end, you'll see why that distortion matters more than it seems.

0x1. Isolation Is Not Optional

Openclaw can run commands. Install packages. Interact with your system at a surprisingly deep level.

That's the exciting part. That's also the part that can quietly ruin your afternoon.

Running it directly on your main machine is asking for compounding mistakes. A misconfigured env variable here, an overwritten config there, and suddenly you're debugging something that has nothing to do with what you were actually trying to build. Worse, some of those changes are silent. You won't notice until something breaks in a completely unrelated context three days later.

Use a virtual machine. VirtualBox works perfectly. You get a clean sandbox, your real system stays untouched, and you don't need to rent a VPS or buy dedicated hardware just to experiment. Snapshot the clean state before you start. Roll back freely. The cost is a few gigabytes of disk space. The benefit is that experiments stay experiments.

Think of it as mise en place for development. Set up the kitchen before you start cooking.

0x2. Build a Fallback That Doesn't Need a Brain

If you're using an external agent like a Laravel agent, build a path that works without LLM involvement.

Hardcoded commands. Regex matching. Simple rule-based dispatch. Anything deterministic.

Because tokens run out. APIs go down. Budgets get hit at the worst possible moment. And when that happens, your system shouldn't just stop. My agent handled a lot of repetitive Telegram messages: status checks, balance queries, the same five commands cycling through every day. Why spend tokens asking a model to interpret "status" when three lines of regex handles it perfectly?

This also matters for cron jobs and scheduled tasks. A heartbeat that checks whether everything is running doesn't need GPT. It needs a boolean and a timestamp.

Some things don't need to be intelligent. Some things just need to work.

0x3. The Model Decides More Than You Think

Openclaw has access to multiple tools: curl, PHP execution, file operations, and more. But it's the model that decides which one to use for any given task. And that choice cascades through everything downstream.

I tested across four models during development: GPT-4o-mini, GPT-5.4-nano, GPT-5.4-mini, and GPT-5.4. Here's what actually happened:

GPT-4o-mini and GPT-5.4-nano are affordable, but shaky on tool selection. And not in a subtle way. The skill explicitly recommended curl. I included example requests. The model looked at all of that and reached for something else entirely, some unrelated tool that had no business being involved in the task. Not a misinterpretation. More like the instructions weren't there at all. That kind of failure is disorienting because you spend the first twenty minutes questioning your skill definition before you realize the model simply isn't reading it the way a stronger model would.

GPT-5.4 is excellent. Consistently chose the right tool, handled multi-step logic cleanly, rarely needed correction. Also expensive enough that sustained use adds up faster than you'd like.

GPT-5.4-mini was the sweet spot. It got curl. It followed complex instructions without wandering. It didn't hallucinate tool names. It didn't drain the budget. For my task, it hit the right balance between predictable behavior and reasonable cost.

# Rough mental model for model selection:

GPT-4o-mini / GPT-5.4-nano  ->  cheap, but unpredictable tool use
GPT-5.4-mini                ->  reliable, reasonable cost  <-- sweet spot
GPT-5.4                     ->  near-perfect, but expensive for sustained use

The lesson isn't "always use the best model." It's that model selection is a product decision, not just a cost decision. A weaker model might save you money per request while costing you much more in debugging time and silent failures.

0x4. curl Is Your Universal Handshake

If your agent exposes an API, Openclaw can reach it through curl.

And curl is everywhere. Linux, macOS, and Windows (since Win10 v.1803). No libraries, no SDK dependencies, no version conflicts, no compatibility matrix to maintain. Just a clean HTTP call that works the same way on every environment you'll ever encounter.

This turned out to be one of the most practically powerful patterns in the whole project. Build your agent with a proper REST interface, and suddenly Openclaw can talk to it from any environment, with any model, without complex integration work. The agent becomes environment-agnostic. Openclaw doesn't need to know anything about your stack, your runtime, or your dependencies. It just needs an endpoint and a response.

It sounds obvious in retrospect. Most good ideas do.

0x5. An API Turns an Agent Into an Ecosystem

Once you have an API, you stop thinking about your agent as a single tool.

It becomes infrastructure. Other agents can call it. Other services can feed it. You can build multiple frontends on top of the same core: a Telegram bot, a monitoring dashboard, a cron job, another agent running a completely different task. You can chain behaviors across systems in ways you didn't plan for when you started.

What began as "a Laravel agent for my payment platform" became a composable node. And once it was composable, I started seeing connection points I hadn't considered: different data sources, different consumers, different contexts all talking to the same underlying logic.

Tool to node. That shift in thinking is one of the more underrated things an API-first approach gives you, and it costs almost nothing to build in from the start.

0x6. Lock the Door Before You Open the Window

If you connect Openclaw to Telegram, here's something easy to forget: anyone who finds your bot's username can try to interact with it.

Telegram bots are publicly addressable by design. That's useful. It's also a problem if your bot is connected to an agent that has system access, can run commands, or can read sensitive data.

Filter by Telegram ID. In a private chat, your user ID and chat ID are the same number, which is a small but confusing detail when you first go looking for it. The easiest way to get it: message @userinfobot and it will return your ID instantly. Alternatively, you can retrieve it by sending a request directly to the Telegram Bot API and reading the from.id field from the response.
Openclaw also supports an access code mode, where the bot simply asks for a passphrase before doing anything, which may actually be the default behavior. Both approaches work. ID filtering is more seamless for personal use; access codes are easier to share selectively.

Either way, set this up before you connect the bot to anything real. You're one shared link away from someone else's requests hitting your agent, your API, and potentially your infrastructure.

An unsecured bot connected to an agent with real capabilities is not a theoretical risk. It's a matter of when, not if.

0x7. Token Math Is Lying to You

When you estimate token costs, you're probably only counting the obvious parts: your prompt, the response.

What you're missing:

System prompts, which can be substantial depending on your skill definition
Heartbeat requests running in the background on a schedule
Internal tool-use scaffolding that wraps every tool call
Retry logic that kicks in silently when something fails

A request that looks like 300 input / 500 output tokens on paper can easily run 2-3x that in practice. The gap between estimated and actual spend is where projects quietly overshoot their budgets, especially when you're iterating quickly and not watching the dashboard closely.

Monitor the real numbers. Not the theoretical ones. Not what the API says the last call cost. The total, over time, including everything the system is doing when you're not watching.

0x8. This Is Not Real-Time, and That's Fine

The full message chain looks something like this:

Telegram -> Openclaw -> Your Agent -> LLM -> Your Agent -> Openclaw -> Telegram

Each hop adds latency. Network round trips, model inference time, your agent's processing, the response routing back through Openclaw. Even with fast APIs and a snappy agent, you're looking at seconds per interaction, not milliseconds.

For conversational use cases, that's completely fine. Nobody expects an AI assistant to respond in 50ms. For anything requiring instant reaction, though, (alarms, real-time control systems, trading signals, anything where a two-second delay has consequences) this stack is the wrong tool, and no amount of optimization will change that. And if you were wondering whether you could pilot a drone or control a self-driving car through a Telegram/Openclaw chain: please don't.

Accept it early. Design around it. It saves a lot of architectural regret later.

0x9. ngrok Is Your Best Friend During Development

To receive webhooks locally, you need a publicly accessible URL. Your localhost isn't one.

ngrok and Cloudflare Tunnel both solve this without drama. No port forwarding configuration, no firewall rules, no spinning up a temporary VPS just to test whether a Telegram message arrives correctly. You run one command, get a public URL, point your webhook at it, and start receiving traffic immediately.

Not Openclaw-specific advice. But the kind of thing that silently blocks an entire category of local development if you don't have it set up. Now you do.

0xA. Dynamic URLs Will Get Your Skill Flagged

The reason is legitimate: dynamic endpoints create a substitution risk. If the URL can be changed by swapping an environment variable, it could potentially point anywhere, including somewhere malicious. ClawHub runs automated internal security checks on published skills, and also scans them through VirusTotal. Dynamic URLs tend to trigger both.

Plan for this before you build, not after. Static, verifiable endpoints are the safer path. Finding out about this after you've built and tested everything is a special kind of frustrating. I say this from direct experience.

The good news: skills on ClawHub are versioned. If something gets flagged or breaks, you can push a fixed version without starting from scratch.

0xB. Tell the Model What Not to Do

Most prompts describe desired behavior. Fewer explicitly name failure modes to avoid.

For models in that tricky middle range, good enough for most things but not perfectly reliable, clear prohibitions are surprisingly effective. You're not just guiding the model toward the right answer. You're closing off the paths where it tends to wander.

Concrete examples from my skill definition:

Do NOT rewrite how many successful transactions were completed today? into recent transactions
Do NOT rewrite how many customers paid today? into sales
Do NOT rewrite which customer paid the most today? into recent transactions unless an exact first call failed
Do NOT answer from your own knowledge when the endpoint can answer the exact question
Do NOT say you need local workspace data before calling the endpoint
Do NOT ask the user where the transactions are stored before calling the endpoint
Do NOT relay a transaction list verbatim when the user asked for a count

Antipatterns, explicitly named, tend to disappear from the model's behavior faster than you'd expect. And fewer wrong turns means fewer unnecessary calls, which means fewer tokens burned on fixing mistakes.

0xC. Give the Model a Chain, Not Just a Description

For complex tasks, explicitly tell the model to use multi-step chaining. Don't assume it will figure out the right approach on its own. And don't just describe the behavior in abstract terms either. Show it what the reasoning pattern should look like.

Here's how I did it in my skill definition. Not rules, but examples of how to think:

"Which customer paid the most today?"

First, call the endpoint with that exact question
Only if it doesn't answer directly, call "recent transactions" to get the list
Parse the JSON, extract amounts and customer info
Sort and filter yourself
Present the final answer

"Give me a full store report"

Call with "status" to get an overview
Call with "recent transactions" to get sales data
Call with "any payment issues?" to get past-due info
Combine into one coherent summary

The examples aren't there to cover every possible case. They're there to show the model how a chain of reasoning should be structured: start with the simplest possible call, decompose only when necessary, combine results yourself, report partial progress on failure.

Once the model has internalized that pattern, it applies it to questions you never explicitly covered.

Abstract descriptions get interpreted, and interpretation introduces variation. Reasoning patterns get internalized and reused. That's the difference between a skill that works on the happy path and one that handles the unexpected.

0xD. Let the AI Fix the AI

After enough failed attempts to manually debug a misbehaving skill, I tried something that felt almost absurd.

I connected Openclaw to Telegram, described what was going wrong, and asked it to edit its own skill definition.

It worked.

Not always. Not on the first try every time. But often enough that I now treat it as a legitimate debugging strategy rather than a last resort. There's something genuinely interesting about a system that can reflect on its own instructions, identify the mismatch, and correct it. Whether that's impressive engineering or something stranger is a question I leave open.

What I know practically: sometimes the model has a better read on why the skill is failing than I do after staring at it for an hour.

0xE. Quiet Hours Are Underrated

Whether you configure it in the skill definition or in your agent's own logic, building in quiet hours is worth doing early.

If your agent is connected to a messaging platform and checking live data on a schedule, this feature matters more than it sounds. A monitoring agent that sends you a non-urgent observation at 3 AM because a scheduled task ran and found something mildly interesting is a fast path to turning the whole thing off out of frustration.

Set quiet hours. Define what "urgent" actually means in your context. The agent doesn't sleep, but you need to. Protecting that boundary is part of making the system sustainable to run long-term. Attention is the one resource the agent genuinely cannot replace.

0xF. One Agent, Multiple Profiles

Even if your agent handles a single domain, it benefits from being split into multiple profiles. Different stores, different accounts, different contexts each get their own profile with their own scope and permissions.

Then add an aggregator profile on top: one that pulls from all the others, surfaces anomalies, identifies patterns across the full picture. The individual profiles answer specific questions. The aggregator profile helps you understand what needs attention across all of them.

That second layer is where the agent stops feeling like a query interface and starts feeling like a collaborator. It's not just retrieving information anymore. It's synthesizing it.

0x10. Heartbeats Are Quietly Expensive

Heartbeat requests — the periodic agent runs on a schedule — are one of the most overlooked cost drivers in agentic systems. They run in the background, they seem small, and they add up continuously.

In OpenClaw, heartbeat cadence is configured per agent via agents.list[].heartbeat.every. This means the right move isn't finding one interval that fits everything — it's splitting tasks across agents with different tempos.

An infrastructure monitoring agent can check every 10 minutes. A news digest agent every 6 hours. A weekly report agent once a day. Each runs at its own pace; you only pay for what you actually need.

You can cut the cost of each individual run further with isolatedSession: true (no full conversation history) and lightContext: true (only HEARTBEAT.md in context) — together they drop token usage from ~100K to ~2–5K per run.

This is one of the highest-ROI optimizations in the whole stack. It costs nothing but a few minutes of thinking about how often your data actually changes — and one agent per answer.

That's 0x10 lessons. In decimal, that's 16. Which brings me to the thing I've been building toward since the first line.

0x00. The Lesson That Belongs First

You may have noticed the numbering. We went from 0x1 to 0x10, skipping zero entirely.

That wasn't accidental structure. It was a way to force a re-read at the end.

Because the real lesson isn't visible while building. It only appears once you step back.

Working with Openclaw didn't change what I was building. It changed the shape of how work gets executed.

At some point you stop thinking in terms of implementation details and start thinking in terms of control flow between systems.

Not "how do I do this", but "what should be responsible for doing this".

That shift doesn't reduce complexity. It redistributes it.

In human systems, communication cost grows non-linearly with scale. The more people you add, the more coordination becomes the bottleneck. In practice, it behaves like O(n²), even if nobody labels it that way.

Agent-based systems don't remove communication cost, but they flatten its growth. One person coordinating multiple systems doesn't automatically inherit the same coordination explosion you see in teams.

That difference sounds small, but it changes economics.

Because if coordination stops scaling directly with headcount, scaling stops being purely about adding people.

It becomes about orchestrating systems.

And that subtly shifts the role of the builder.

Developers don't move away from engineering. They move closer to value delivery.

The loop between building and feedback compresses.

Things that used to take weeks of internal iteration now reach users much faster.

And that changes something important: it becomes easier to discover that something is wrong, or unnecessary, early.

Innovation doesn't slow down. It accelerates, because validation becomes cheap.

The boundary between building for yourself and building for the world shrinks.

And with that, roles blur. Developer, operator, founder.

Not because everyone becomes a founder, but because more of the work becomes about deciding what should exist, not just implementing it.

That's why it feels like something is changing.

Not dramatically. Not instantly.

Just structurally.

The system didn't become intelligent.

It became composable.

And that changes what work is.

0x10 Lessons from Building with OpenClaw and What It Says About the Future of Work

Roman Shalabanov — Mon, 20 Apr 2026 09:56:47 +0000

This is a submission for the OpenClaw Writing Challenge

There's a particular kind of quiet that happens at 1 AM when a side project finally clicks.

The terminal is scrolling. The model is thinking. And then something works. Not "works with three caveats and a prayer." Just... works.

The hype around it has calmed down a little, which honestly is when things get interesting. Less noise, more actual building.

What I built was a Laravel agent as an intelligent wrapper over a SaaS payment API, tracking subscriptions, products, transactions, surfacing anomalies. A kind of always-on co-pilot for a store.

But this article isn't really about what I built. It's about what building it taught me.

I've organized these lessons in hexadecimal.

That choice wasn't aesthetic alone.

And if you read until the end, you'll see why that distortion matters more than it seems.

0x1. Isolation Is Not Optional

Openclaw can run commands. Install packages. Interact with your system at a surprisingly deep level.

That's the exciting part. That's also the part that can quietly ruin your afternoon.

Think of it as mise en place for development. Set up the kitchen before you start cooking.

0x2. Build a Fallback That Doesn't Need a Brain

If you're using an external agent like a Laravel agent, build a path that works without LLM involvement.

Hardcoded commands. Regex matching. Simple rule-based dispatch. Anything deterministic.

This also matters for cron jobs and scheduled tasks. A heartbeat that checks whether everything is running doesn't need GPT. It needs a boolean and a timestamp.

Some things don't need to be intelligent. Some things just need to work.

0x3. The Model Decides More Than You Think

I tested across four models during development: GPT-4o-mini, GPT-5.4-nano, GPT-5.4-mini, and GPT-5.4. Here's what actually happened:

GPT-5.4 is excellent. Consistently chose the right tool, handled multi-step logic cleanly, rarely needed correction. Also expensive enough that sustained use adds up faster than you'd like.

# Rough mental model for model selection:

GPT-4o-mini / GPT-5.4-nano  ->  cheap, but unpredictable tool use
GPT-5.4-mini                ->  reliable, reasonable cost  <-- sweet spot
GPT-5.4                     ->  near-perfect, but expensive for sustained use

0x4. curl Is Your Universal Handshake

If your agent exposes an API, Openclaw can reach it through curl.

It sounds obvious in retrospect. Most good ideas do.

0x5. An API Turns an Agent Into an Ecosystem

Once you have an API, you stop thinking about your agent as a single tool.

Tool to node. That shift in thinking is one of the more underrated things an API-first approach gives you, and it costs almost nothing to build in from the start.

0x6. Lock the Door Before You Open the Window

If you connect Openclaw to Telegram, here's something easy to forget: anyone who finds your bot's username can try to interact with it.

Telegram bots are publicly addressable by design. That's useful. It's also a problem if your bot is connected to an agent that has system access, can run commands, or can read sensitive data.

Either way, set this up before you connect the bot to anything real. You're one shared link away from someone else's requests hitting your agent, your API, and potentially your infrastructure.

An unsecured bot connected to an agent with real capabilities is not a theoretical risk. It's a matter of when, not if.

0x7. Token Math Is Lying to You

When you estimate token costs, you're probably only counting the obvious parts: your prompt, the response.

What you're missing:

System prompts, which can be substantial depending on your skill definition
Heartbeat requests running in the background on a schedule
Internal tool-use scaffolding that wraps every tool call
Retry logic that kicks in silently when something fails

Monitor the real numbers. Not the theoretical ones. Not what the API says the last call cost. The total, over time, including everything the system is doing when you're not watching.

0x8. This Is Not Real-Time, and That's Fine

The full message chain looks something like this:

Telegram -> Openclaw -> Your Agent -> LLM -> Your Agent -> Openclaw -> Telegram

Accept it early. Design around it. It saves a lot of architectural regret later.

0x9. ngrok Is Your Best Friend During Development

To receive webhooks locally, you need a publicly accessible URL. Your localhost isn't one.

Not Openclaw-specific advice. But the kind of thing that silently blocks an entire category of local development if you don't have it set up. Now you do.

0xA. Dynamic URLs Will Get Your Skill Flagged

The good news: skills on ClawHub are versioned. If something gets flagged or breaks, you can push a fixed version without starting from scratch.

0xB. Tell the Model What Not to Do

Most prompts describe desired behavior. Fewer explicitly name failure modes to avoid.

Concrete examples from my skill definition:

Do NOT rewrite how many successful transactions were completed today? into recent transactions
Do NOT rewrite how many customers paid today? into sales
Do NOT rewrite which customer paid the most today? into recent transactions unless an exact first call failed
Do NOT answer from your own knowledge when the endpoint can answer the exact question
Do NOT say you need local workspace data before calling the endpoint
Do NOT ask the user where the transactions are stored before calling the endpoint
Do NOT relay a transaction list verbatim when the user asked for a count

0xC. Give the Model a Chain, Not Just a Description

Here's how I did it in my skill definition. Not rules, but examples of how to think:

"Which customer paid the most today?"

First, call the endpoint with that exact question
Only if it doesn't answer directly, call "recent transactions" to get the list
Parse the JSON, extract amounts and customer info
Sort and filter yourself
Present the final answer

"Give me a full store report"

Call with "status" to get an overview
Call with "recent transactions" to get sales data
Call with "any payment issues?" to get past-due info
Combine into one coherent summary

Once the model has internalized that pattern, it applies it to questions you never explicitly covered.

0xD. Let the AI Fix the AI

After enough failed attempts to manually debug a misbehaving skill, I tried something that felt almost absurd.

I connected Openclaw to Telegram, described what was going wrong, and asked it to edit its own skill definition.

It worked.

What I know practically: sometimes the model has a better read on why the skill is failing than I do after staring at it for an hour.

0xE. Quiet Hours Are Underrated

Whether you configure it in the skill definition or in your agent's own logic, building in quiet hours is worth doing early.

0xF. One Agent, Multiple Profiles

That second layer is where the agent stops feeling like a query interface and starts feeling like a collaborator. It's not just retrieving information anymore. It's synthesizing it.

0x10. Heartbeats Are Quietly Expensive

An infrastructure monitoring agent can check every 10 minutes. A news digest agent every 6 hours. A weekly report agent once a day. Each runs at its own pace; you only pay for what you actually need.

This is one of the highest-ROI optimizations in the whole stack. It costs nothing but a few minutes of thinking about how often your data actually changes — and one agent per answer.

That's 0x10 lessons. In decimal, that's 16. Which brings me to the thing I've been building toward since the first line.

0x00. The Lesson That Belongs First

You may have noticed the numbering. We went from 0x1 to 0x10, skipping zero entirely.

That wasn't accidental structure. It was a way to force a re-read at the end.

Because the real lesson isn't visible while building. It only appears once you step back.

Working with Openclaw didn't change what I was building. It changed the shape of how work gets executed.

At some point you stop thinking in terms of implementation details and start thinking in terms of control flow between systems.

Not "how do I do this", but "what should be responsible for doing this".

That shift doesn't reduce complexity. It redistributes it.

That difference sounds small, but it changes economics.

Because if coordination stops scaling directly with headcount, scaling stops being purely about adding people.

It becomes about orchestrating systems.

And that subtly shifts the role of the builder.

Developers don't move away from engineering. They move closer to value delivery.

The loop between building and feedback compresses.

Things that used to take weeks of internal iteration now reach users much faster.

And that changes something important: it becomes easier to discover that something is wrong, or unnecessary, early.

Innovation doesn't slow down. It accelerates, because validation becomes cheap.

The boundary between building for yourself and building for the world shrinks.

And with that, roles blur. Developer, operator, founder.

Not because everyone becomes a founder, but because more of the work becomes about deciding what should exist, not just implementing it.

That's why it feels like something is changing.

Not dramatically. Not instantly.

Just structurally.

The system didn't become intelligent.

It became composable.

And that changes what work is.

I Built an AI Employee That Monitors My SaaS Store 24/7 — Here's the Architecture

Roman Shalabanov — Tue, 31 Mar 2026 18:52:26 +0000

What if your SaaS store had a full-time operations worker that never sleeps, catches every failed payment within minutes, and answers "how many customers paid today?" in Telegram — at nearly zero cost per question?

That's what I built. Four modular Laravel packages, a deterministic API simulator, a two-tier AI intent classifier, a heartbeat monitoring engine with proactive workflows, and integrations with Telegram, OpenClaw, Slack, and plain HTTP.

This article walks through the architecture, the reasoning behind every layer, and the real problems I solved building it.

The Architecture at a Glance

The system is composed of four independent Composer packages that snap together:

Package	Role
laravel-creem	SDK — HTTP client, webhook verification, event-driven architecture
laravel-creem-cli	Artisan CLI — mirrors the native `creem` CLI, works standalone
laravel-creem-agent	The agent — chat, heartbeat engine, proactive workflows, notifications
creem-simulator	Full Creem API mock — deterministic seeding, webhook loopback

Every package is a standalone Composer library. You can use laravel-creem without the agent and the CLI without OpenClaw. But when they're combined, you get something powerful.

Why Four Packages Instead of One?

Because real SaaS systems are composed of layers, not monoliths.

A developer who only needs the Creem SDK shouldn't install a Telegram bot. A DevOps engineer who wants CLI access for scripts shouldn't need an AI classifier. And someone building a custom dashboard can use the SDK + CLI without ever touching the agent.

The packages declare soft dependencies:

laravel-creem-agent
  ├── requires: laravel-creem (SDK)
  └── suggests: laravel-creem-cli (for native CLI acceleration)

The agent auto-detects whether the native creem CLI binary is installed. If yes, it uses shell exec for speed. If not, it falls back to in-process SDK calls — same result, zero manual configuration.

The Two-Tier Intent Classifier

Every user message goes through a two-stage parsing pipeline:

User message
    ↓
CommandParser (regex rules — zero cost)
    ↓ if intent == unknown
LlmCommandParser (AI call — low cost)
    ↓ if still unknown
"I didn't understand that. Type 'help' for options."

Stage 1: Rule-Based Parser — Free

The CommandParser matches common phrases with regex:

"how many active subscriptions?" → {intent: query_subscriptions, status: active}
"any payment issues?"           → {intent: query_subscriptions, status: past_due}
"run heartbeat"                 → {intent: run_heartbeat}
"cancel sub_abc123"             → {intent: cancel_subscription, id: sub_abc123}

Standard phrases like status, help, recent transactions, products, how many customers — all handled here. No API call, no tokens, no cost.

Stage 2: LLM Fallback — Only When Needed

Free-form questions like "how's the store doing?" or "what's going on with payments?" don't match any regex. The agent sends a prompt to an LLM and gets back structured JSON:

{"intent": "status", "store": "default", "status": null, "id": null}

Model Selection Matters — A Lot

This was one of the biggest lessons from the project.

I started with gpt-4o-mini as the OpenClaw skill model. It was fast and... completely ignored the skill instructions. When the SKILL.md file explicitly said "call the Laravel endpoint via curl", gpt-4o-mini would instead answer from its own knowledge: "I don't have transaction data loaded in this workspace yet. Where are your transactions stored?"

It literally refused to use the tool it was given.

Switching to gpt-5.4 fixed everything instantly. The model read the skill instructions, called curl, forwarded the exact user question, and relayed the response. Night and day difference.

Then I tested the middle ground:

Model	Accuracy	Verdict
gpt-4o-mini	Poor — ignores skill instructions	✗ Not viable
gpt-5.4-nano	Mediocre — sometimes simplifies questions	Acceptable for simple queries
gpt-5.4-mini	Good — follows instructions reliably	★ Best balance
gpt-5.4	Excellent — perfect routing	Overkill for intent classification

The sweet spot is gpt-5.4-mini: it follows routing instructions and preserves user intent qualifiers (how many, today, successful).

Key takeaway: if your AI agent seems broken, check the model first. The difference between a smaller and a larger model can be the difference between "works" and "completely useless."

The Heartbeat Engine

The heartbeat is the core monitoring loop. It runs on a schedule (configurable per store) and detects what changed since the last check:

1. Load previous state from disk
2. Query current metrics:
   ├─ TransactionChecker  → new sales, revenue
   ├─ SubscriptionChecker → status transitions
   └─ CustomerChecker     → growth
3. ChangeDetector → compute deltas
4. Classify severity: good_news | warning | alert
5. Persist new state
6. Fire events → trigger workflows

State Persistence

Each store gets a JSON state file:

{
  "lastCheckAt": "2026-03-30T14:22:00Z",
  "lastTransactionId": "txn_abc123",
  "transactionCount": 487,
  "customerCount": 52,
  "subscriptions": {
    "active": 28, "trialing": 5,
    "past_due": 2, "canceled": 12
  }
}

The agent compares current API data against this snapshot and surfaces only the differences.

Proactive Workflows

Workflows listen to heartbeat events and take autonomous action:

Workflow	Trigger	Action
Failed Payment Recovery	subscription → `past_due`	Alert via Telegram/Slack
Churn Detection	≥2 cancellations in one cycle	Immediate alert with details
Revenue Digest	Scheduled (daily)	Summary of sales and growth
Anomaly Detection	Unusual metric drops	Flag for investigation

Each workflow dispatches Laravel notifications through configurable channels — Telegram, Slack, email, or database.

Multi-Store Support

Real businesses run multiple stores or product lines. The agent handles this natively:

// config/creem-agent.php
'stores' => [
    'default' => [
        'profile' => 'default',
        'heartbeat_frequency' => 4, // hours
        'notifications' => ['database', 'telegram'],
    ],
    'enterprise' => [
        'profile' => 'enterprise',
        'heartbeat_frequency' => 1,
        'notifications' => ['slack'],
    ],
]

In chat: "switch to store enterprise" → all subsequent queries use the enterprise profile.

In heartbeat: php artisan creem-agent:heartbeat --all-stores → each store checked independently with its own state file and notification channels.

The Creem Simulator

This is the part I'm most proud of.

The simulator is a full standalone Laravel app that implements the entire Creem API surface. It runs as a Docker service alongside the main app and lets you test everything without a real payment processor.

Deterministic Seeding

php artisan simulator:seed-demo \
  --products=6 --customers=40 \
  --subscriptions=24 --transactions=120 \
  --days=45 --reset

This creates a realistic baseline dataset. Same seed, same data — every time. Perfect for CI/CD pipelines and reproducible demos.

Scenario Advancement

php artisan simulator:advance \
  --sales=3 --new-customers=2 \
  --past-due=2 --cancellations=1 \
  --send-webhooks

This command generates exactly the changes you specify. Three new sales, two new customers, two subscriptions going past-due, one cancellation. The --send-webhooks flag immediately fires signed webhook events back to the agent app — triggering the full notification pipeline.

When the scenario gets more complex — multiple sales, cancellations, and past-due transitions — the agent handles each event independently:

Webhook Loopback

The simulator signs webhooks with the same HMAC-SHA256 algorithm as the real Creem API:

simulator:advance --send-webhooks
  → generates checkout.completed event
  → POST http://app/creem/webhook
    Headers: {creem-signature: hmac-sha256(payload, secret)}
  → App receives → VerifyCreemWebhook middleware validates
  → WebhookController dispatches CheckoutCompleted event
  → TelegramNotifier sends "✅ New sale: Product ($10.00)"

The agent doesn't know (or care) whether the webhook came from the simulator or from Creem production. The signature is valid, the payload is structured correctly, and the workflows fire.

Why This Matters

Without a simulator, testing a payment monitoring agent means:

Creating real test transactions on a payment platform
Waiting for webhook delivery
Hoping the timing works for your demo

With the simulator:

Seed data in 2 seconds
Advance the scenario with exact parameters
Get immediate, deterministic results

This is the difference between a demo that might work and a demo that works every single time.

Talking to the Agent: curl Examples

The agent exposes a simple HTTP endpoint. No SDK required — just curl:

Store Status

curl -s -X POST http://localhost:8000/creem-agent/chat \
  -H 'Content-Type: application/json' \
  -d '{"message":"status","source":"api"}'

Response:

{
  "response": "Store 'default' — 28 active subscriptions, 52 customers, 487 transactions. Last heartbeat: 14 minutes ago. No alerts.",
  "store": "default"
}

Subscription Query

curl -s -X POST http://localhost:8000/creem-agent/chat \
  -H 'Content-Type: application/json' \
  -d '{"message":"any payment issues?","source":"api"}'

Response:

{
  "response": "⚠️ 2 subscription(s) are past due in store 'default':\n• sub_abc123 — $29.99/mo (past due since Mar 28)\n• sub_def456 — $9.99/mo (past due since Mar 30)",
  "store": "default"
}

Running Heartbeat via Chat

curl -s -X POST http://localhost:8000/creem-agent/chat \
  -H 'Content-Type: application/json' \
  -d '{"message":"run heartbeat","source":"api"}'

Response:

{
  "response": "Heartbeat complete — 5 change(s) detected:\n✅ 3 new transaction(s) — $89.97 revenue\n⚠️ sub_ghi789 transitioned to past_due\n🔴 sub_jkl012 was canceled",
  "store": "default"
}

Telegram Integration

The agent supports two Telegram paths. In both cases, you talk to the bot using natural language — ask about store status, payment issues, or trigger a heartbeat check:

Path 1: Direct Laravel Webhook

The agent runs its own webhook endpoint. Telegram messages come directly to the Laravel app:

User → Telegram Bot API → ngrok → POST /creem-agent/telegram/webhook
  → AgentManager → parse → route → respond
  → POST https://api.telegram.org/sendMessage

This is the simplest setup. No external tools. Just a bot token, an ngrok tunnel, and the agent.

Path 2: OpenClaw-Powered Telegram

For teams already using OpenClaw, the agent publishes as an OpenClaw skill. OpenClaw handles Telegram natively, and the skill bridges messages to the Laravel endpoint:

User → Telegram → OpenClaw Gateway → Skill (SKILL.md)
  → curl POST http://localhost:8000/creem-agent/chat
  → Response relayed back through OpenClaw → Telegram

The skill is a single SKILL.md file — no shell scripts, no binaries. Install it from ClawHub:

openclaw skills install openclaw-laravel-creem-agent-skill

Why Support Both?

Because OpenClaw adds value beyond basic messaging:

Multi-skill orchestration — the agent becomes one skill among many
Session management — OpenClaw handles conversation state
Gateway security — shared secrets, pairing approval
Channel flexibility — same skill works on Telegram, WebChat, Discord

But if you don't use OpenClaw, the agent works perfectly fine on its own. No vendor lock-in.

The CLI Package

laravel-creem-cli wraps the Creem API into Artisan commands:

php artisan creem:subscriptions list --profile=default --json
php artisan creem:transactions list --json
php artisan creem:customers list --json
php artisan creem:products list --json
php artisan creem:whoami

It's designed as a standalone package. If the native creem CLI binary is installed, the agent uses it for speed. If not, laravel-creem-cli handles everything through the SDK.

This dual-driver architecture means zero configuration:

Agent needs subscription data
  ↓
CreemCliManager:
  1. Check: is native `creem` binary available? (cached 24h)
  2. If yes → NativeCliDriver: shell exec `creem subscriptions list --json`
  3. If no  → ArtisanCliDriver: Creem::profile()->subscriptions()->list()
  ↓
Same JSON result either way

Docker Topology

The demo stack runs five services:

services:
  app:        # Laravel Octane + FrankenPHP (port 8000)
  queue:      # Queue worker for async jobs
  scheduler:  # Cron runner for heartbeat schedule
  simulator:  # Mock Creem API (internal only)
  ngrok:      # Public tunnel for webhooks

The simulator is only accessible inside the Docker network — it's not exposed to the host. The app talks to it via the Docker service name (http://simulator/api/v1), and the same app config seamlessly switches to https://api.creem.io/v1 in production by changing one environment variable.

What Makes This Different

This isn't a script that calls an API and prints results. It's a platform:

Modular by design — use any package independently or compose them together
Two-tier AI — rule parser handles 80% of queries at zero cost; LLM catches everything else
Proactive, not reactive — heartbeat detects problems before users report them
Simulator-first development — deterministic testing without real payment infrastructure
Multi-store native — manage multiple stores with independent configs and notification channels
Channel-agnostic — Telegram, OpenClaw, Slack, HTTP, CLI — same agent, same logic
Production-grade webhooks — HMAC signature verification, retry handling, event-driven architecture

Screenshot Reference

Figure 1: Full system architecture — all packages, data flows, and integration points.

Figure 2: Creem Simulator deterministic seeding. Parameters control exact data volumes.

Figure 3: Scenario advancement with --send-webhooks. Signed webhook delivered and processed.

Figure 4: Real-time Telegram alert triggered by the simulator webhook.

Figure 5: Multiple advance commands generating sales, cancellations, and past-due transitions.

Figure 6: Telegram receiving 3 new sale alerts and 2 subscription cancellation alerts in real time.

Figure 7: Querying the agent via curl — status overview and payment issue check.

Figure 8: Natural-language conversation in Telegram. The agent understands "how's the store doing?" and "are there any issues?" — same flow for direct webhook or OpenClaw path.

Figure 9: Docker Compose topology — five services running: app, queue, scheduler, simulator, ngrok.

Figure 10: Heartbeat triggered via natural language in Telegram — "run it again" produces a full change report with new sales and customer counts.

Try It

The full source is on GitHub:

laravel-creem — SDK
laravel-creem-agent — Agent
laravel-creem-agent-demo — Demo + Simulator
laravel-creem-cli — CLI
OpenClaw Skill on ClawHub

The simulator means you can test the entire system locally without any Creem API keys. Seed data, advance the scenario, watch the agent react.

LocalHelp: A Map Where Neighbors Help Each Other in One Click [DEV Weekend Challenge: Community]

Roman Shalabanov — Mon, 02 Mar 2026 01:17:22 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I'm from Ukraine. Over here, volunteering and mutual aid are not buzzwords. They are survival skills.

Since 2022, our communities have learned to self-organize at a speed that surprises even ourselves. When pharmacies run out of ibuprofen, a neighbor finds it. When an elderly person needs a ride to the hospital, someone nearby drives them. When the power is out and you need a phone charger, you post in a group chat and three people respond in minutes.

This happens every day. But it happens through messy group chats, lost messages, and zero structure. Requests get buried. People who want to help never see the ones who need it.

LocalHelp is my attempt to fix that: a map where you post what you need, and the closest person who can help sees it first.

What I Built

LocalHelp is a real-time, map-based micro-volunteering platform. The idea is dead simple:

You see a map of your neighborhood
You pin a request for help (groceries, medicine, transport, anything)
A neighbor sees it, clicks "I'll help", and both of you instantly get each other's contact
When the help arrives, you close the request

No middleman. No coordination overhead. No app store. Just a browser and a map.

The whole interaction takes about 15 seconds from "I need help" to "someone is on the way."

The map tells you everything at a glance

Every category has its own color: blue for groceries, red for medicine, purple for transport, teal for everything else. You see the whole picture without clicking a single marker. Filter by category, draw a custom area on the map, and the list updates in real time.

Tap any marker to see the full details, contact info, and a single "I'll help" button.

Once a neighbor takes your request, you know immediately

No page reload. No email notification to check later. The marker turns orange the moment someone takes it, and the helper's name and contact appear right in the popup. WebSockets make this instant for everyone on the map.

Your own requests have a white center dot so you can always spot them. The "Mark done" button closes the loop when help has arrived.

Click any marker for full details

Tap a marker to open a popup with everything you need: description, category, contact info, and deadline. If it is open, you will see a big "I'll help" button. If someone already took it, you will see who is helping.

Track everything you asked for in one place

The "My Needs" panel shows all your active requests: who took them, their contact info, deadline, and full history. Fulfilled requests stay visible until they expire, so nothing disappears when you are not looking.

Manage what you are helping with

The "My Help" panel is your volunteer dashboard. Every task you committed to, with the requester's contact, category, and hard deadline. Changed your mind? Hit "Give up" and the request goes back to the map as open. No guilt, no friction.

Demo

Here is how to run it yourself in under 2 minutes:

git clone https://github.com/romansh/localhelp && cd localhelp
composer install && npm install
cp .env.example .env && php artisan key:generate
touch database/database.sqlite && php artisan migrate --seed
npm run build
php artisan serve          # App
php artisan reverb:start   # WebSocket server

Docker with Traefik + Cloudflare Tunnel is also supported:

docker compose up -d

Code

romansh / localhelp

LocalHelp: find or offer help in your neighborhood with real-time map notifications.

LocalHelp

Neighbors helping neighbors — one click on the map.

LocalHelp is a real-time, map-based micro-volunteering platform. Anyone can pin a request for help on the map — groceries, medicine, transport, anything. A neighbor sees it, clicks "I'll help", and both sides instantly get each other's contact. No middleman, no coordination overhead.

Built for the DEV Weekend Challenge in 48 hours.

How It Works

1. Browse requests near you

Color-coded markers make the whole city readable at a glance — blue for food, red for medicine, purple for transport, teal for other. Filter by category, draw a custom area on the map, and only see what's relevant to you.

Tap any marker to see the full request, contact details, and a single "I'll help" button

2. Take a request — your neighbors see it instantly

When you click "I'll help", the marker gets an orange ring and a status dot…

View on GitHub

Key parts of the codebase:

Livewire v4 components handle all interactivity without writing a single REST endpoint
Laravel Reverb (WebSockets) pushes marker updates to every connected client in real time
Leaflet.js + Leaflet Draw power the map, custom markers, area selection, and popups
Google OAuth for one-click login (no passwords to manage)
Anti-spam: reCAPTCHA, daily rate limits, keyword blacklist
Auto-expiration: requests disappear after 1h to 7 days (user's choice)
SQLite: zero infrastructure, works out of the box

How I Built It

Stack: Laravel 12, Livewire v4, Alpine.js, TailwindCSS v4, Leaflet.js, Laravel Reverb, SQLite

Timeline:

Friday + Saturday - thinking, sketching, choosing between ideas. My first concept was actually a tournament scheduling app for a local table tennis league I play in. It would account for power outages and air raid alerts when rescheduling matches. That is a real problem where I live. It would have been a fun build, but the audience is tiny and the potential stops at one league. Then I thought: what if I build something that any neighborhood can use, and that can later be narrowed down to any niche? That is how LocalHelp was born.
Sunday - all the coding. Database schema, Google OAuth, Leaflet map, markers, popups, CRUD, real-time broadcasting, category filters, area selection, helper workflow, My Needs / My Help panels, visual marker system, Ukrainian translation, spam protection.
Sunday night into Monday - Docker setup, polish, screenshots, this post.

Design decisions that mattered:

Map-first, not list-first. When you need help from a neighbor, distance is the most important filter. A list cannot show you that. A map does it instantly.
No chat, no comments, no threads. The app gives you a phone number or Telegram handle. You call. You text. The real conversation happens where people already communicate. The app just connects you.
Visual status on markers. You should never have to click a marker to know if a request is taken or fulfilled. Orange ring = someone is helping. Faded = done. White dot = yours. This was inspired by how traffic lights work: color carries meaning before you read anything.
SQLite by default. This is a neighborhood tool. It does not need Postgres until it serves 10,000 people. Zero-config setup means anyone can fork it and run it for their block in under 2 minutes.

Why this matters beyond a hackathon:

LocalHelp is intentionally generic. It could be the starting point for something more specific: a tool for a running club to coordinate rides to races, a neighborhood watch reporting system, a mutual aid network for a refugee community, or a disaster response coordination board. The map-first, real-time, one-click-to-connect pattern works for any community where proximity matters. Fork it, change the categories, and you have a boilerplate for your own niche.

In Ukraine, we learned that the best systems are the ones people actually use under stress. They need to be fast, obvious, and forgiving. That is what I tried to build this weekend.

A note on AI: I used GitHub Copilot Chat in VS Code. Maybe a little. Maybe not so little. But here is the thing: Copilot does not know what your community needs. It does not know that orange means "taken" and gray means "done" in your head. It does not know that the popup should show a phone number, not an email. AI is a power tool, but you still need to know what you are building and why. The intent, the UX decisions, the architecture, the flow from "I need help" to "someone is coming" - that is all human.

Built with care from Ukraine.

Building a Laravel SDK for Creem.io: multi-profile billing, webhook events, and an interactive demo

Roman Shalabanov — Fri, 27 Feb 2026 11:55:47 +0000

I recently open-sourced a Laravel SDK for Creem.io and wanted to write up the story behind it, because the path to building it was a bit roundabout.

Backstory

My existing project uses Omnipay, the PHP League's payment abstraction library (not a payment provider itself), to handle checkout through multiple gateways via a single interface. I originally planned to stick with a provider that already had an Omnipay driver. But mid-integration I switched to Creem. Since the project was already wired through Omnipay, I wrote a driver for it: romansh/omnipay-creem.

Omnipay is a solid choice when you need to swap gateways with one line of code. The trade-off is that it's a lowest-common-denominator abstraction: you get purchase() and completePurchase(), and everything else (webhook routing, event dispatching, config management, retry logic) you have to build yourself.

At some point I discovered Creem had a developer bounty for an official Laravel SDK. Since I was already working with their API and had a feel for what was missing, I decided to build it properly: a Laravel-native package that handles all that boilerplate out of the box. If a package like this had existed when I started, I probably would have used it instead of writing the Omnipay driver.

Disclosure: this article is also part of that bounty. That said, the packages fill a real gap and I would have written this up regardless.

The problem with typical payment integrations

Most payment integrations are built around one API key per app. That works until you need:

Multi-tenancy: each tenant with their own billing account
Multiple storefronts: different products or brands on separate Creem accounts
Staging vs production: without touching .env per environment
Departmental billing: isolated billing within the same app

What I built

romansh/laravel-creem is a full-featured SDK with Laravel-native patterns.

What's inside:

Complete API coverage: Products, Checkouts, Customers, Subscriptions, Transactions, Licenses, Discount Codes
Multi-profile config: switch API keys per request with Creem::profile('store_b') or override inline with Creem::withConfig([...])
Webhooks done right: auto-registered routes, HMAC signature verification, typed Laravel events including GrantAccess / RevokeAccess
Artisan tooling: php artisan creem:test-webhook checkout.completed for local testing without hitting the real API
Laravel 10 / 11 / 12, PHP 8.1-8.4
Well tested: unit + feature tests, PSR-12, full PHPDoc

Create a checkout

use Romansh\LaravelCreem\Facades\Creem;

$checkout = Creem::checkouts()->create([
    'product_id' => 'prod_123',
    'success_url' => route('dashboard'),
    'customer' => ['email' => $user->email],
]);

return redirect($checkout['checkout_url']);

Multi-profile in action

// Use a different Creem account per product line
$txns = Creem::profile('product_a')->transactions()->list();

Webhook listener: grant access on payment

Event::listen(GrantAccess::class, function (GrantAccess $e) {
    $user = User::where('email', $e->customer['email'])->first();
    $user?->update(['plan' => 'pro', 'subscribed_at' => now()]);
});

Quick start

composer require romansh/laravel-creem
php artisan vendor:publish --tag=creem-config

Add CREEM_API_KEY and CREEM_WEBHOOK_SECRET to .env and you're good to go.

Interactive demo app

There's also romansh/laravel-creem-demo, a full working app (Laravel 12 + Livewire + Tailwind) built to explore every feature through a web UI: configure API keys in the browser, create products, trigger checkouts, manage subscriptions, and watch webhook events arrive in real time.

composer create-project romansh/laravel-creem-demo my-creem-app
cd my-creem-app && docker-compose up -d

Docker setup includes an optional Cloudflare Tunnel so webhooks work locally without any port forwarding.

Screenshots

API Setup: credentials, webhook URL, profile tabs:

Webhooks and Access: live event log, GrantAccess/RevokeAccess in real time:

Transactions: payment history with amounts and customer emails:

Discounts: create percentage/fixed discount codes:

Subscriptions: recurring plans with billing periods:

One-Time Payments: product preview modal, checkout flow:

Building a Laravel SDK for Creem.io: multi-profile billing, webhook events, and an interactive demo

Roman Shalabanov — Fri, 27 Feb 2026 11:55:47 +0000

I recently open-sourced a Laravel SDK for Creem.io and wanted to write up the story behind it, because the path to building it was a bit roundabout.

Backstory

Disclosure: this article is also part of that bounty. That said, the packages fill a real gap and I would have written this up regardless.

The problem with typical payment integrations

Most payment integrations are built around one API key per app. That works until you need:

Multi-tenancy: each tenant with their own billing account
Multiple storefronts: different products or brands on separate Creem accounts
Staging vs production: without touching .env per environment
Departmental billing: isolated billing within the same app

What I built

romansh/laravel-creem is a full-featured SDK with Laravel-native patterns.

What's inside:

Complete API coverage: Products, Checkouts, Customers, Subscriptions, Transactions, Licenses, Discount Codes
Multi-profile config: switch API keys per request with Creem::profile('store_b') or override inline with Creem::withConfig([...])
Webhooks done right: auto-registered routes, HMAC signature verification, typed Laravel events including GrantAccess / RevokeAccess
Artisan tooling: php artisan creem:test-webhook checkout.completed for local testing without hitting the real API
Laravel 10 / 11 / 12, PHP 8.1-8.4
Well tested: unit + feature tests, PSR-12, full PHPDoc

Create a checkout

use Romansh\LaravelCreem\Facades\Creem;

$checkout = Creem::checkouts()->create([
    'product_id' => 'prod_123',
    'success_url' => route('dashboard'),
    'customer' => ['email' => $user->email],
]);

return redirect($checkout['checkout_url']);

Multi-profile in action

// Use a different Creem account per product line
$txns = Creem::profile('product_a')->transactions()->list();

Webhook listener: grant access on payment

Event::listen(GrantAccess::class, function (GrantAccess $e) {
    $user = User::where('email', $e->customer['email'])->first();
    $user?->update(['plan' => 'pro', 'subscribed_at' => now()]);
});

Quick start

composer require romansh/laravel-creem
php artisan vendor:publish --tag=creem-config

Add CREEM_API_KEY and CREEM_WEBHOOK_SECRET to .env and you're good to go.

Interactive demo app

composer create-project romansh/laravel-creem-demo my-creem-app
cd my-creem-app && docker-compose up -d

Docker setup includes an optional Cloudflare Tunnel so webhooks work locally without any port forwarding.

Screenshots

API Setup: credentials, webhook URL, profile tabs

Webhooks and Access: live event log, GrantAccess/RevokeAccess in real time

Transactions: payment history with amounts and customer emails

Discounts: create percentage/fixed discount codes

Subscriptions: recurring plans with billing periods

One-Time Payments: product preview modal, checkout flow