From Crow's Nest to Home Port

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.