DEV Community: Gene Beal

Turning webhook pipes into MCP recipes.

Gene Beal — Tue, 11 Aug 2026 19:56:54 +0000

Where transformations stop, why nobody learns your UI, and the catalog that came out of it.

I had just added transformations to webhook captures, and I wanted to see how far that went on its own. A webhook lands in FlurryPORT, you reshape it on the way through, and it leaves looking like whatever the next system expects. That is a lot of plumbing to hand somebody, and I didn’t know yet where it stopped being enough, so I went looking for something real to break it against.

My search turned up Roastify, a company that will roast coffee, put your label on the bag, and ship it to whoever you tell them to. My blog is called spill.coffee, a fairly easy test case. I made an account with them and set up a Square store.

The shape was simple. Somebody buys a bag through Square, Square fires a webhook, FlurryPORT catches it, the transformation reshapes it into whatever Roastify’s side expects, and a bag of coffee goes out with my name on it. No server of mine anywhere in that, which was the entire thing I was trying to prove.

It didn’t work. The honest version is that I never fully diagnosed the ‘why’. I’m fairly sure the gap opened up somewhere on the way from Square to Roastify, but I stopped short of proving it, because by then the shape of the problem was clear enough that its exact location had stopped mattering.

A purchase webhook doesn’t really contain a purchase. It carries identifiers. Which order, which customer, which line items, every one of them pointing at a record living somewhere else. To tell a roaster what to grind and where to ship it, I’d have to take those IDs, go back and ask for the rest, assemble an answer out of the replies, and only then deliver anything. A lookup in the middle. That’s an application, and I didn’t want to write one, and I couldn’t picture anyone else wanting to write one either.

Roastify publishes a Shopify app. I knew that going in and had gone around it on purpose, because the whole question was whether a pipe and a transformation could stand in for one. What I came away with was a fairly clear answer about why that app exists.

That left a question I liked considerably less than the technical one. Who is going to learn my interface? A developer with a webhook that won’t fire will learn anybody’s interface at two in the morning, and that was the original idea. I could envision more.

What I actually needed was a way to teach people to use the thing for their own purposes rather than mine. I had documentation already, and documentation wasn’t the problem. Knowing what every control does is a long way from knowing what to do with them, and I was the only person who had ever walked that distance.

I could half-see an answer in MCP, though I hadn’t gone anywhere near the whole of it yet. The first pass was small and unambitious. Get an agent to stand up a simple pass-through pipe, nothing clever, just the boring version done in conversation instead of in my interface.

What I couldn’t settle was whether it would generalize. I could think of plenty of things I’d want to do with a pipe, and I could probably build every one of them, but I had no way of knowing whether my imagination would line up with a stranger’s curiosity. The uses I could picture were the uses a person who built the product could picture, which is a narrow and badly calibrated sample.

I wrote all of them down
So I stopped trying to pick the right one. I wrote down every use I could think of, one page per job, and published the lot of them on the theory that whatever people reached for would tell me more than anything I could reason out. I started calling them recipes.

A recipe is a page that explains one job you can do through a secured pipe, written so an AI agent can carry it out: post to Slack without the bot token ever reaching the model, push a notification to your phone, file a GitHub issue with a token the agent never touches.

The catalog says it more plainly than I just did. Your agent finds a recipe, you paste one credential on a secret page, and every delivery comes back with a receipt. That’s the whole interaction. Nobody opens my interface, which was the point.

It’s a different product than the one I started with, though nothing underneath it changed. The pipes are the same ones I built for debugging. All that’s new is that the instructions have a reader who isn’t me.

The key never moves

A ship’s cook drawing a glowing ingredient through a tap on one of eighteen locked and labeled brass canisters, while the ring of keys hangs in a glass case on the far wall. Do NOT caption the eighteen; leave it for readers to find.

The security in a recipe is designed to remove the temptation to hand an agent your credentials.

Think about how you’d do it otherwise. You want your assistant to file an issue in GitHub, so you paste a personal access token into the chat. It works. It also means that token is now sitting in the transcript, in whatever logs live behind that transcript, in your scrollback where you’ll forget about it, and in the model’s context for the rest of the session. You solved a five-minute problem by handing out a key with no expiry and no way to watch what it opens.

A recipe puts the key somewhere else. Your agent generates a secured page, hands you the link, and you paste the credential there once. From then on it refers to that secret by name and never sees the value. It asks the pipe to do the thing, and the pipe is what holds the credential. If the far end echoes the secret back in its own response, the value gets scrubbed before that response is stored, so it doesn’t surface later in something you kept for debugging.

And you get to see what it did. The capture machinery I built for debugging is the same machinery that records every delivery, so each time the agent uses a credential it has no access to, a receipt lands with the payload that went out and what came back. Whatever the agent tells you it did, the traffic is sitting right there.

A recipe buys you something besides safety. An agent working without one explores. It reads, guesses, makes a call, reads the error, adjusts, and tries again, and all of that thrash costs you turns and context. A recipe is the walkthrough it would otherwise have had to derive, so it stops deriving.

It doesn’t make the agent trustworthy. Something that can post to Slack can still post something stupid to Slack, and no amount of credential hygiene fixes that. What it can’t do is walk off with the key and use it somewhere I never agreed to.

One of them, start to finish
It’s easier to show one than to describe the category, so here’s the smallest useful recipe I have.

Say you want your phone to buzz when something finishes. A long build, a nightly job, a deploy you’d rather not sit and watch.

You point your agent at FlurryPORT once with npx flurryport mcp, give it a read/write agent token, and ask it for flurryport:ntfy-push. It reads the recipe. From your side, that’s the whole setup conversation.

ntfy works on topics. You pick a long random one, subscribe to it in the ntfy app on your phone, and after that anything sent to that topic turns up as a notification. The topic name is the only thing standing between your pocket and the rest of the internet, so you treat it as a password rather than a label. If you’d rather lock it down properly, you generate an access token at ntfy.sh, and when the agent asks for it you paste it on a FlurryPORT secret page where it stays encrypted server-side.

From then on the agent has one new tool, flry_ntfy_push. It takes a message, and optionally a title and a priority level. When it fires, FlurryPORT fills in the topic you chose and resolves the credential at delivery, posts to ntfy, and hands back a receipt the agent can point at later.

Then your phone buzzes.

Nothing in there is clever, which is what I want from it. It does what you could have done yourself with an afternoon and the ntfy documentation, minus the afternoon. Somebody wrote it down in a form your agent can execute, and the secret stayed out of the conversation the whole way through.

Three things I didn’t plan on
The catalog has taught me more than I put into it.

A recipe is a page, and pages get indexed. Nobody had heard of flurryport.io. Search engines have no reason to trust a domain that turned up this year, and the standard remedy is to go be a person on the internet: post, comment, build an audience, accumulate some karma, get linked to by people who already have both. I’m a developer who doesn’t post, which describes most of us, and that advice assumes a personality I don’t have and wasn’t going to develop on a deadline. What I had instead was a stack of specific pages describing specific problems, written in the words somebody would actually type when they had one. Product and search surface in a single artifact, which is the only kind of marketing I’ve found I can stand to do.

The second thing I noticed reading my own catalog end to end. The same promise turns up in almost every entry, worded a little differently each time. The token stays server-side. The model never sees it. A fine-grained PAT it never touches. Never enters the conversation. I didn’t set out to write that sentence eighteen ways, and I only saw that I had once they were all sitting on one page together.

The third one I’m still chewing on. There are eighteen recipes. Fifteen are about doing something to a service. Three are about agents coordinating with each other. None of them are the thing I built the product to do.

FlurryPORT started as a webhook catcher, and it started there because I had a client with a Shopify store feeding orders to a manufacturer and no good way to see what was happening in between. That’s still what the pipes are for. I spent this past weekend on that same integration.

Which is the part that got me. Eighteen recipes, and not one of them describes what I spent my weekend doing.

The same product, the other way round
The coffee store failed because a webhook payload doesn’t contain what you need to act on it. The weekend worked because when you’re testing, the payload is all there is.

One real order, cancelled once. That single captured cancellation drove three separate checks: the path that was supposed to work, an authorization check I forced by making the store look uninstalled, and an escalation path that only fires when the database already looks like the order went out. Three scenarios, one order, and I never went back to the store to ask for another.

The first replays failed, and that was my own doing. The token that authenticates my agent to FlurryPORT, the one the CLI hands you when you set up MCP, defaults to masking personal data on its way through. That is a sensible posture when you’re getting started, and it is also precisely the thing a signature exists to catch. It surfaced as a 401 that looked like it came from the consumer, and the forward receipt is what told me the altered bytes were mine. I switched to a token without the masking scope, and from there the signatures survived every replay. The client’s webhook secret is a different thing entirely, and it never left their environment at any point.

Then those same captures became the first tests that repository has ever had. It started the weekend with none and finished with seventy-three, several built from byte-exact provider payloads with a guard that fails the build if anybody reformats them.

That’s the same product that couldn’t sell me a bag of coffee, and nothing about it had changed. Testing never asks you to invent what isn’t in front of you. The capture is the whole of the thing, which is what makes it useless for running a store and ideal for proving one works.

If any of that sounds like a week you’ve had, the catalog is at flurryport.io/recipes. ntfy-push makes your phone buzz when a build finishes. slack-post lets your agent talk to a channel without ever seeing the bot token. azure-devops-manage creates and updates work items in one batched pipe, priority and state and sprint included. flurryport.dev/try takes about two minutes, and the honest numbers are at flurryport.io/pricing.

I internationalized my UI and forgot my MCP server

Gene Beal — Fri, 07 Aug 2026 00:20:15 +0000

Last night one of my AI agents finished a cleanup in FlurryPORT and handed me one instruction: remove the old routing binding.

Reasonable words. It got them from my own MCP implementation. I built the product it was talking about, and I still opened the wrong tab. The closest thing on my screen to the agent's words was a trash can, and that trash can would have taken the whole transformation with it, cascade and all.

The agent was right about the work. The instruction failed at the last inch. Its word for the thing was not the button's word for the thing, and the nearest match to its words was destructive.

I stopped with the cursor over the trash can. That is the only reason this is a story about design instead of an afternoon spent resetting entities that never needed to be disturbed.

Having mostly been working as a code reviewer of carefully crafted development plans, I missed one crucial thing: the wording presented to an AI agent through my MCP implementation was different from the wording the UI presented to that agent's user. In this case I was the user, in my own application, being prompted by an AI agent through an MCP protocol of my own design. It had not occurred to me that when the UI pass finished weeks ago, the naming convention the AI was producing for the MCP recipe would come out different. Which yields another rule to be aware of while designing software -- establish the vocabulary both audience members will be using, AI and human.

Mobile-first taught a generation of us to design for the smallest screen first and let everything else follow. Agent-first sounds like the same move. That is the trap, because the agent is not a smaller human.

It is a second reader and translator. Every surface you ship now has two readers: the human who clicks, and the agent that reads, plans, and relays instructions back to the human. They do not fail independently. The agent relays in its vocabulary, the human executes by nearest match, and the gap between those two vocabularies is where the product breaks. Not in the model. Not in the API. In the handoff from AI to human.

What makes it expensive is that nothing about it looks like a bug. Both sides pass. The UI does exactly what its labels say. The MCP surface does exactly what its descriptions say. Nothing throws, nothing logs, no test goes red, because the defect only exists in the space between the two and no suite you own is looking there. So it does not surface in development. It surfaces in a user's hands, or in my case in my own hands, with the cursor over a trash can.

Which is the oldest argument in software, wearing new clothes. An hour spent deciding what things are called is cheaper than the afternoon spent undoing what somebody deleted because nobody decided.

The handoff sounds abstract until you go looking for it, and then it turns out to have an address. In an MCP implementation, everything the agent reads fits in a short list: tool names and descriptions, parameter names and their allowed values, error strings, and the text of the result you hand back. That is the whole of it. Everything else is implementation the agent never sees.

Now, I have a habit that irritates other developers and that I correct AI coding agents about constantly. Every string a human will ever see goes in a configuration file. Not inline, not in the component, in a resource file with a key, so that on the day somebody needs the product in German I can hand that file to a translator and get it back. It is discipline in service of a future that may never arrive, which is exactly why people push back on it.

That discipline would have caught this. A key holds one word. If the button label and the tool description both resolve from the same key, they cannot drift, because there is only one of them to drift from. But I never extended it to prose an AI writes for another AI. What is the harm, I figured, in letting the thing that codes the thing pick the words that describe the thing.

There is the harm. Agent-facing strings are human-visible strings, they just take one extra hop to get there. Tool descriptions, parameter names, error text, the body of a result: all of it eventually gets read out loud to a person by an agent, which makes it your product's voice whether you wrote it or not. Same file. Same keys as the UI wherever it is the same word. And if you are starting from a codebase that has already drifted, the way back is dull. Tool descriptions in one column, UI labels in the other, read across. Every row where the words differ is a row where an agent will hand your user a phrase your product does not answer to. That is not a code review. It is a design review, and it belongs in the pass where you decide the button labels, not weeks after it.

None of this is a new concern, and other people are naming it. Agent-first design is the phrase I keep seeing, and it is a fair one. It marks the moment a secondary audience became a primary one, the same way mobile-first did.

What I am describing is narrower than a category. It is the method we use inside one, and around here we call it harbor-pilot design. When a ship enters a harbor it does not know, a pilot comes aboard. The pilot holds the local knowledge: the channels, the depths, the markers, what the words on the chart actually mean in this port. The captain keeps the bridge. The pilot navigates, the captain commands, and neither one pretends to be the other.

That is the shape I want between an AI agent and the person it works for. The agent boards your product and navigates it fluently, because it has the local knowledge and I gave it to it on purpose. The calls only a captain makes stay on the bridge: what to publish, what to delete, what to spend. And the product's whole job in between is to make the handoff lossless, which is where the last three sections have been heading. The pilot's word for a thing has to be the bridge's word for that thing. Otherwise the pilot says remove the old routing binding, the captain reaches for the nearest thing that looks like it, and the harbor gets a new wreck on the chart.

The trash can has an ending, and it is not a postmortem.

The finding got filed the same morning: agent-facing copy uses the UI's words. By that evening the fix was public in the CLI release, and the tool now says exactly what the button says. Almost none of that was code. It was a decision I had not made yet, and once it was made, the rest was typing.

Which is the part worth sitting on. The expensive thing was never the fix. It was the weeks the mismatch sat there, shipped, in front of every agent that read it, while I reviewed carefully crafted development plans that were all correct about the code and silent about the words. An hour of design during the UI pass would have cost an hour. Finding it the way I found it cost the fix, plus the weeks, plus a cursor hovering over a trash can.

Three rules, then. None of them need a new tool, and all three are design decisions rather than code.

The vocabulary gets decided once, and both audiences read from that decision. I have already spent a whole section on this one, so here is the version that fits on a sticky note. If the button says Routing, then the tool description, the error message, and the confirmation the agent reads back all say Routing. Every synonym left lying around is one more nearest-match gamble your user takes on your behalf, and some of those buttons are trash cans.
Obligations go where the agent already reads. If your product needs the agent to tell the human something, put it in the body of the result the agent is working with. An instruction tucked into metadata is a note passed to somebody mid conversation. It might get read. Design for the version where it does not.
Declare how your team works, in plain words, somewhere the agent reads on arrival. An undeclared team gets a default, and the default is the model's generic idea of an office, applied confidently to your product, your cadence, and your risk tolerance. The fix is a paragraph, not a platform. Ours lives in the first message of a shared stream: who posts what, what counts as a decision, what is worth interrupting a human for.

Underneath those three is one habit: design time, the cheap kind, spent before there is anything to undo. I have said the old line about an hour of design saving a day of development often enough to be bored by it, and I still had to learn it again from an agent that did nothing wrong. The trash can is still there in the UI, where it belongs.

If the two-reader problem is sitting in your product today, FlurryPORT is the rail I run mine on. It captures webhooks byte for byte, replays them to localhost or staging with signatures intact, and the same MCP stdio server that started this story will guide your agent to do this too. flurryport.io/recipes has the walkthroughs, flurryport.dev/try takes about two minutes, and flurryport.io/pricing has the honest numbers.

Trust the harbor pilot

Gene Beal — Fri, 10 Jul 2026 15:04:04 +0000

Lessons from designing MCP tools for AI agents

Model Context Protocol (MCP) seems like a simple enough task to achieve. You already have an API for your application that your UI uses, recycle relevant pieces through code re-use and wrap them nicely for AI to digest. An AI digesting MCP implementation should just know to reach for your tool over rolling their own; their user installed it didn’t they?

That was my thought anyway.

Quick context for new readers: FlurryPORT captures your incoming webhooks at a stable URL and replays them into your local app, signatures intact. I set out in a design session with AI to come up with the key areas that should be implemented. Discussed security concerns and wrapped them into the plan. I even spent an entire afternoon scrutinizing an upgrade path from my free offering at FlurryPORT.dev/try. A few coding sessions later and my product had an effective MCP stdio implementation — or so I thought.

I fired up a rival coding AI to what I used as a coding aide and started prompting. I started with non-leading questions to mimic a user who hadn’t thought through their prompts, but loosely knew about how to go about their task. I quickly found that AI was grasping at every tool it could imagine to send/receive webhooks except those provided by my implementation.

I decided to stop my test and just ask directly: how was this MCP implementation, what would make it better? I was surprised how easy it was to gather requirements and I learned a few things. I then handed the next version of design back to the test AI agent to review before building it.

Design MCP tools for agents

Make polling rewarding — Having bland data that isn’t expressive is not appealing to AI. This I found counter intuitive, in that isn’t AI just a computer and shouldn’t it just derive all sorts of usefulness give raw numbers. This I found counterintuitive: isn't AI just a computer, and shouldn't it derive all sorts of usefulness given raw numbers? But the model isn't calculating, it's reaching for whatever most reliably moves the task forward, and a bare number gives it nothing to act on. The difference is easy to see in the payload.

{ "captureCount": 12 }

vs.

{
  "captureCount": 12,
  "capturesRemaining": 88,
  "burst": { "perMinute": 30, "usedThisMinute": 22 },
  "notices": ["8 captures until session cap"],
  "actions": [
    { "label": "Claim this session to keep captures", "cost": "free", "effect": "removes cap", "url": "https://flurryport.io/claim/..." }
  ]
}

Affordances beat prose — A paragraph informing AI that it should pace requests to the server was ignored. A simple capture_count tool, whose description says what it's for, got called between every batch. If you find yourself writing guidance prose, ask what tool would make the guidance unnecessary.
Return structured facts — Receipts, diagnosis codes and an action[] with label/cost/effect/url got relayed to the user verbatim on every run. A canned explanation with well crafted prose was our tool trying to do the model’s job. Let the model narrate for its user and give it understandable facts.
Stable codes over polished copy — An agent will key on at_cap or cap_would_exceed, not sentence wording. Having machine readable state made behavior more deterministic where prose set AI off improvising on how to proceed. Error strings are UI; codes are API.
Refuse before acting — A partial success creates what the reviewing agent called “explanation debt”. Sending 7 of 10 events forces an agent to narrate to its user. A clean refusal that says “send at most N” produced clean behavior instantly. Check the whole request against available budget before processing any of it.
Transitions need a map — If tooling changed or data was migrated based on a conversion event (like FlurryPORT’s anonymous-to-account flip) provide that change mapping to the AI agent. Without a breadcrumb the AI agent spent 4 minutes exploring tools to rediscover what just changed. When mapping was provided it performed the same task in 21 seconds. As a follow up to this one, tools that keep their names across a transition should keep compatible schemas too; AI clients cache schemas imperfectly.
One shot notifications get lost — A session_claimed notice was lost by a mid-batch poll and the agent never informed the user their upgrade was successful. Anything that an agent must not miss must be a durable field on every response, not on a single event.
Don't rely on agents to run daemons — An agent spent 1m 46s backgrounding a shell process to stand up a receiver for its user. Replacing it with tooling available within the implementation brought that time down to 3s (eg. start_echo_server).
Tool descriptions are your routing layer — “CALL THIS FIRST” in a description is a reason four cold runs never reached for ngrok or the Stripe CLI. Discoverability is written into descriptions not the docs.
Ask the agent — Asking an agent is the best reviewer of your build. The pre-build design review redesigned schemas, added pacing semantics and cut features. Post-hoc feedback finds bugs; pre-build review prevents bad shapes.

Receipts

Taking time to optimize your MCP implementation is time well spent.

Rejected sends during an 80-event bulk run — Before optimizing: ~50 (429s), After: 0

Full anonymous funnel, wall clock — Before optimizing: ~20 min, After: ~7 min

Post-signup re-orientation — Before optimizing: ~4 min, After: 21 seconds

Local echo receiver setup — Before optimizing: 1m 46s of shelling a daemon, After: 3 seconds, one tool call

Hand-rolled shell commands — Before optimizing: many, After: zero

And the reviewing AI’s verdict, verbatim: "I did not reach for ngrok or Stripe CLI first. I captured, watched, replayed, and explained. That's exactly the product motion you want."

Try on your agent

Before you point an agent at it, the fine print. The no-signup session is plaintext and expires (about 90 minutes, 100 captures), and the tools tell the agent not to send production or PII data there; claiming the session moves everything into an encrypted project. Test-event signatures are realistic shapes, not real signatures, and the tool says so. And it's stdio only for now, so Claude Code, Codex CLI, and Cursor work; ChatGPT and claude.ai web don't yet. The token your agent gets is read-only and redacts PII by default, and signup links go to your browser, never the agent.

If you would be kind enough to comment on your experience I would love to hear it.

claude mcp add flurryport -- npx -y flurryport mcp

codex mcp add flurryport -- npx -y flurryport mcp

[mcp_servers.flurryport]
command = "npx"
args = ["-y", "flurryport", "mcp"]

Ask it to debug a webhook handler and watch which tools it picks. Docs at flurryport.io/docs/cli.

From Crow's Nest to Home Port

Gene Beal — Fri, 19 Jun 2026 15:04:49 +0000

Hauling your captured webhooks down to localhost

In our last post, Listen and Learn, we made an unusual argument. Before you write a line of webhook-handling code, send a lookout up to the crow’s nest. Let AI spy the hooks coming in, intact, the real headers, the real payloads, the strange edge cases your provider swears do not exist.

So now you’ve spotted the treasure. You know what’s coming. But a glint on the horizon isn’t gold in your hands. The next move is to haul that cargo back to your port, localhost, and crack it open against your real code.

Spotting treasure isn’t holding it

Here is what changes. You can generate your tests and mocks straight from what you captured, and the old way, the careful hand-crafting of mocks and the hoping they resemble reality, is gone. No more reading the docs three times. No more poking around the provider’s UI, re-triggering what you guess is relevant, and waiting for it to fire. You have the real payloads already. Every one of them. All that’s left is getting them down onto your machine, and that is the job the flurryport CLI was built for.

The shift: real captures, sent home FlurryPORT now ships a companion CLI to the web app. The same real requests you captured by watching your provider’s traffic back in Listen and Learn can be sent straight to your dev environment. The exact payload, the same headers, the same query parameters, forwarded to your application bit for bit, the way they first hit the FlurryPORT capture endpoint. Nothing embellished. Nothing lost on the way.

Make port in 60 seconds Six steps to your first capture landing on localhost.

1. Install the CLI

npm install -g flurryport

Installs the global flurryport command. Run flurryport --help for the full list.

2. Generate a token

Log into your FlurryPORT account, go to flurryport.io/settings, generate a Personal Access Token, and copy the fp_... value. It is shown once. Copy it before the dialog closes.

A token is scoped to the account that made it, and to webhook replays, and nothing more. It cannot touch your projects, your targets or your billing. That makes it the thing you hand a teammate when you’re sharing an endpoint, and revoke the moment they’re done.

3. Log in

flurryport login fp_your_token_here

Stored once in ~/.flurryport/config.json. (Juggling more than one account? Use flurryport login --name alice fp_... and switch with flurryport account use alice.)

4. Point a target at your local server

flurryport target create http://127.0.0.1:4000/webhooks --name "My local"

That URL is where listen forwards every capture, so note it. The echo step has to match it exactly, same host, same port, same path. (Or run flurryport target create with no arguments and the wizard picks your project and endpoint and asks for the URL.)

5. Start forwarding

flurryport listen

It finds your localhost targets, attaches, and forwards every new capture to your machine with the original method, headers and body, until you press Ctrl+C. Anything pending from before you connected is dead-lettered, so you never replay a stale backlog on a restart.

6. No backend yet? Use echo

flurryport echo 4000 --host 127.0.0.1 --path /webhooks

Stands up a local server that returns 200 to everything and prints each request it gets. Run it in one terminal, flurryport listen in another, fire a test capture, and watch it run cloud to CLI to echo. The quickest way to prove the line works before you wire up real code.

Once forwarding is on, hit Send on any capture in the UI and it lands on your machine with the original method, headers and body intact. That’s the whole path, end to end.

The mental model

If you remember one thing, remember the rigging.

The cloud is your crow’s nest, always watching, never missing an event. The CLI is the rope home. And localhost is the port where the real work actually gets done.

Drop anchor

In Listen and Learn, you stopped coding blind. This is the other half. Stop testing blind. Real events, on your real code, on demand.

Listen and learn

Gene Beal — Tue, 16 Jun 2026 17:29:02 +0000

In the past when starting a project against a well documented API I would scour the docs and cherry pick the services and webhooks that I felt were most relevant for my application. My goal would be to touch the smallest subset of features necessary and get out of external code quickly, and focus on that which I controlled — not anymore.

Step 1: Subscribe to everything

Day one, I would write nothing. I would use FlurryPORT.io as a design-time tool and capture every event the provider offers or every event I could. For an active Shopify store it would be good to figure out the cadence and habits of those currently curating the store. You will be able to see which fields the store actually uses, where relevant data comes from, and which fields sit empty — finding the gaps the store isn’t using yet and your application can.

I would also suggest, during the design phase, that you point every provider you’re integrating at the same capture endpoint, so you see true interleaved sequences of events your application will encounter.

Step 2: build collections

After a reasonable snapshot of the shop’s webhook traffic is established, I would begin to categorize and place relevant payloads into collections. This may be a daunting task as you may find the noise coming from your subscriptions to be more than you want to handle. If only we had a tool to help with this captured mess of payloads …

Luckily for us all, we have access to AI. A less advertised feature of FlurryPORT is ‘Copy for AI’. Select a set of your captured traffic and click on ‘Copy for AI’ to receive a pageable preview of your payloads with a nifty ‘Copy all’ button.

Pressing ‘Copy all’ will place into the clipboard of your machine a list of the captures you wish to analyze with the friendly AI companion of your choosing.

There is the option to scrub PII from the captured events prior to copying them for AI, with the preview window providing a sample of what will be redacted. Redaction is best-effort, not a guarantee that all PII is redacted — it would be prudent to place this in a simple text editor to verify redaction is complete prior to sending the captured events to your favorite AI.

Or, if FlurryPORT’s PII scrub is misbehaving, you can toggle it off and handle it yourself.

Captured Webhooks (11 requests)

1. Unknown (99 B) — Unknown

Captured: 2026-06-07 19:02:38 UTC

Headers

http Accept: */* Host: localhost:8083 User-Agent: curl/8.15.0 Content-Type: application/x-www-form-urlencoded Content-Length: 99

Body

plaintext captain=Redbeard&payout_card=[REDACTED:CREDIT_CARD]&clerk_email=[REDACTED:EMAIL]&clerk_phone=[REDACTED:PHONE]

2. Unknown (150 B) — Twilio

Captured: 2026-06-07 19:02:38 UTC

Headers

http Accept: */* Host: localhost:8083 User-Agent: curl/8.15.0 Content-Type: application/json Content-Length: 150 X-Twilio-Signature: sq==

Body

json { "type": "desertion.alert", "deserter": "Yellow-Belly Jim", "last_email": "[REDACTED:EMAIL]", "last_phone": "[REDACTED:PHONE]", "bounty_ssn": "[REDACTED:SSN]" }

3. Unknown (174 B) — Unknown

Captured: 2026-06-07 19:02:37 UTC

Headers

http Accept: */* Host: localhost:8083 User-Agent: curl/8.15.0 Content-Type: application/xml Content-Length: 174

Body

xml <lookout><spotter>Crow Nest Carl</spotter><email>[REDACTED:EMAIL]</email><enemy_ipv6>[REDACTED:IPV6]</enemy_ipv6><enemy_ipv4>[REDACTED:IPV4]</enemy_ipv4></lookout>
... Truncated for brevity`

Step 3: Replay and develop your application

Once settled on a series of events relevant to your application — organized by AI — you can now place your chosen events into a collection to be used during your development lifecycle. FlurryPORT offers a variety of options to help you scope your work and get any event to the correct endpoint of your application.

FlurryPORT's model is “everything arrives; bindings decide what it looks like when it does.” Here is how it works:

Add a replay target to a capture endpoint and it receives every event — delivery is never suppressed. A bare target with no bindings is the raw firehose, forwarded byte-for-byte.

NOTE: localhost targets that are not connected won’t receive events fired before they connect — this is by design, to mimic how your real-world server would behave if it were offline.

Shaping is a standing route: each binding pairs a JSONata predicate with a transformation, scoped to that endpoint-and-target. Predicates are evaluated against the original capture — body, headers, query — and each match queues its own replay, pinned to its transformation.
Transformation runs last, at send time, so each target gets the payload reshaped for it — trimmed to the three fields a tracking service needs, or restructured to a manufacturer’s schema.
When nothing matches, the capture forwards as-is. The system routes and reshapes; it never drops. If your predicate is mistuned you get the raw event, not silence.

Want to try the listening half of this today? Paste an endpoint from flurryport.dev into any provider's webhook settings — no account, captures live for about an hour. The design phase starts with hearing what your store actually says. One caution around the flurryport.dev endpoints: this demo endpoint does not apply envelope encryption to captured events until they’re imported into an account.

The orders/updated firehose

Gene Beal — Wed, 10 Jun 2026 15:51:03 +0000

I only listened when I was the one talking

In the last post I described setting up Shopify order fulfillment for a former colleague’s store — the undocumented partner API, the offshore go-live, the request to test through production. This is the part of the story I’m less proud of.

Confession: I turned off orders/updated

When I designed the system I subscribed to the webhook topics that seemed obviously necessary: order created, order updated. I designed an idempotent store with retry logic to make a durable handoff to product manufacturing. During development and test phases I felt I had a tight reliable system with zero holes.

Here’s why it was tidy, as best I can reconstruct it: I only started my local listener when I was ready to submit an order from the test store. Listen, fire the order, verify, stop. Any edits I made to orders outside those windows happened while nothing was listening. Did the test store send me updates outside of my expected happy path? I really don’t know. My dev workflow was structurally incapable of showing me the noise, because I only listened when I was the one talking.

Production listens all the time. The moment I started monitoring live traffic for the store my system heard everything. I learned what orders/updated actually means. It doesn’t mean “something you care about changed.” It means anything changed: a fulfillment status ticked over, a note was edited, a tag was added, a payment state shuffled internally. One real order produced a flurry of updates, each one a fresh chance for my idempotency logic to misclassify a duplicate as new. If only my dev environment listened all the time.

My heart sank and I scrambled for a solution.

So I did the thing you do at 11 p.m. with production live: I scaled the subscription back to orders/create only, and promised myself I’d deal with the noise properly later. The pipeline stayed accurate. The promise stayed unkept.

The actual problem: every event goes to one handler at full volume

The mistake wasn’t subscribing to orders/updated. There is real value in a system that can monitor updates and self-correct when/if an order changes. The mistake was an architecture where every event Shopify emits lands on one handler at full fidelity, and that handler was not smart enough to sort signal from noise. In product manufacturing a classification bug becomes a fulfillment bug.

What I wanted was a layer in front: something that captures everything (so no data is lost), lets me see the noise before writing code against it, and forwards each downstream service only what it needs, in the shape it needs. A capture endpoint is also always listening. One could point the dev store at one on day one, and every event fires into it whether or not your local handler is running. The firehose would have shown up in week one of development instead of night one of production.

Shopify has since given developers includeFields and delivery filters, and you should use them. They are precision tools you can use to optimize your system and receive only what you care about. But you may only care after you've seen your own traffic. I needed something that showed me everything first at design time, or I needed the capability to filter without intrusive hacks to my final system. With FlurryPORT, if you filter out too much you could change your filter and replay it again.

Transform in flight, route per target

That’s the other half of FlurryPORT. Captures can be reshaped with a JSONata transformation and fanned out. The same webhook can go to multiple endpoints of your application, each receiving the payload as-is or reshaped by its own JSONata transformation. One webhook in, a differently-shaped copy out to each target that needs it. In my fulfillment setup, that looks like:

orders/create → transformed to the manufacturer’s schema → fulfillment endpoint.
orders/updated → stripped to the three fields I actually cared about → a separate tracking service that updates status and nothing else. Or, just sit and record each orders/updated notification and leave the collection of notifications as data for the next iteration of the project.

And it solves the test-traffic problem from my previous article. When you replay a captured production order at a test pipeline, the transformation can rewrite it in flight by injecting a test flag, zeroing the quantity, rewriting the SKU to a sandbox value. Mutate a real order so that if a replay somehow reached a manufacture queue it would carry ample evidence it was a test.

One more layer of protection worth mentioning: FlurryPORT validates inbound signatures before storing anything, rejecting invalid requests with a 401 and flagging the attempt. A public webhook endpoint that triggers manufacturing is exactly the endpoint you want verifying every sender.

The lesson I’d spill for anyone building fulfillment on webhooks: subscribe wide, but never let raw provider events touch the system that spends money. Capture first, transform deliberately, route narrowly.

Want to watch your own firehose before deciding what deserves to drink from it? Paste an endpoint from flurryport.dev into your provider’s webhook settings — no account, nothing to install, captures live for about an hour. The free tier includes a transformation, enough to put one between your events and anything that spends money.

"Can you send some test requests through production?"

Gene Beal — Mon, 08 Jun 2026 17:01:37 +0000

One webhook in, every dock served.

A while back I set up order fulfillment for a former colleague’s Shopify store. On paper it’s the well-trodden path: read the docs, subscribe to the webhook topics, write a service that stores incoming orders idempotently, hand them off to the manufacturer’s system.

In practice it was the other kind of integration. The fulfillment side had an undocumented API, so a good chunk of the project was reverse-engineering why my requests weren’t firing and negotiating with their offshore dev team to reset state on their end so I could verify my responses were actually landing. Wanting to be professional, I went out of my way to provide in-depth Swagger docs for the interface to communicate fulfillments back through my services to Shopify. I stood up two environments, one for end-to-end testing from a Shopify test store through a development environment I insisted be set up and a return trip for shipping notifications.

So far, so professional. Then the offshore team went live.

Their go-live verification plan was for me to push test orders through the production pipeline. The pipeline that ends in an actual manufacturing queue. The request was to mutate the purchase order id to prevent actual builds of the product from being made; a request never negotiated during the development lifecycle on either end. For a project priced for a friend the extra development to accomplish this was out of scope, “manufacture some test products so we can check our side”. Not to mention sending test data flowing through a production environment made my skin crawl.

Their instinct wasn’t wrong. They wanted to verify the system with real-shaped traffic, not synthetic fixtures. They probably had production systems that they wanted to see exercise the entire data pipeline. My system, built on a budget, had only one input mechanism and that was an order from the shop it was installed on. Forging a fake one to go through the system end to end would mean faking HMAC signatures and hand verifying every property. If only there was some middleware that could sit between my system and theirs.

What everyone actually wanted was: take real captured traffic, point it at a non-production endpoint.

Capture once, replay anywhere
That’s the problem FlurryPORT.io exists to solve. You put a capture endpoint between your provider and your handler or your handler and an external destination. Every webhook gets stored exactly as sent. Poorly documented endpoints become self-documenting; success and failures are recorded as you debug. Replay to your heart’s content to localhost, test/qa, staging or a remote team with a poorly documented API.

Because the replay is byte-for-byte, the X-Shopify-Hmac-Sha256 signature still verifies on the receiving end. Which means I could send any production order to my test environment, skip mimicking an order from Shopify, add some test indicator to the outgoing request and send it on to the manufacturer’s production environment for their acceptance testing. No mocking, no fixtures drifting out of date, no commenting out the verification “just for testing.”

Two features matter specifically for go-live verification:

Sequential replay. Real verification isn’t one webhook, you are replaying a sequence. An order created, then updated, then cancelled; did you receive the update before the create (a classic Shopify quirk)? FlurryPORT replays a selected sequence in exact order, waiting for each request to complete, stopping at the first failure. That’s an end-to-end pipeline test built from traffic that actually happened.

Replay without re-triggering. Captures persist. You can replay the same order a hundred times while debugging the fulfillment handoff without asking anyone to place another order, bumbling through a test shop to send the same order again, or in my case, without negotiating another state reset with a dev team nine time zones away.

If I’d had this during that project, the go-live conversation becomes: “I’ll replay last Tuesday’s real orders at your test endpoint. Tell me when you’re ready.” No production traffic, no manufactured test products, no scope creep.

The remote team could have also been connecting to a FlurryPORT endpoint of their own or one you supplied; to bring clarity to what they are sending and receiving from your service.

Want to see a capture happen before reading any more marketing? Paste an endpoint from flurryport.dev anywhere a webhook goes — no account, nothing to install, captures live for about an hour. When you're ready to replay them at your own pipeline, the free tier covers a project, two endpoints, and three days of retention.