DEV Community: Gene Beal

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.