The words FlurryPORT uses, defined once. Tooltips across the product link here, and every entry has a stable address your agent can cite.
One recorded delivery: everything that arrived at your endpoint, stored byte-for-byte.
Anything that arrives at your endpoint - a Stripe webhook, a test event, a message posted to a shared stream - is stored byte-for-byte: body, headers, query, arrival time. Encrypted at rest. That stored record is a capture.
Captures are what you inspect, replay, and forward. They are also what plans count: each plan includes a monthly capture allowance, and captures age out with your plan’s retention window unless saved to a collection.
Your capture URL: the stable address you point a sender at.
An endpoint is the stable address you point a sender at - a webhook provider, a test script, a team’s stream. Everything that arrives becomes a capture, kept in the order it arrived.
Endpoints belong to a project, and each plan includes a set number per project.
Where captures go next: a destination you register, any HTTP endpoint outside FlurryPORT.
A target is a destination you register - your app on localhost, a staging server, a third-party API. Replay sends a capture to a target on purpose; a binding sends matches automatically.
Local targets are delivered by the CLI on your machine; external targets are delivered from our servers. Each plan includes a set number per project.
Sending a stored capture to a target, on purpose, byte-for-byte with signatures intact.
Replay is deterministic: the capture goes out exactly as it was recorded, signatures intact - one capture, a batch, or an ordered sequence.
When delivery happens automatically instead of by hand, that is auto-forward.
Standing, automatic delivery: matching captures go to a target as they arrive.
Auto-forward is the automatic path: once set up, matching captures are delivered to a target the moment they arrive - no button pressed. Replay is the on-purpose path; auto-forward is the standing one.
Plans include separate allowances for local auto-forward targets (delivered by the CLI on your machine) and external ones (delivered from our servers).
Ad-hoc delivery of a capture to your own machine: the CLI hands it to your localhost, no registered target needed.
Forward sends a capture to a URL on your own machine - you name the port and path, the CLI delivers the exact bytes, and you get a receipt with the response. Nothing is registered and nothing stands; it is the fastest way to hit your handler with real traffic.
Three delivery verbs, three jobs: forward is ad-hoc to your machine, replay is deliberate delivery to a registered target, and auto-forward is the standing path.
The structured record every delivery returns: what was sent, where it went, and how the destination answered.
Every forward, replay, and recipe publish returns a receipt. It records what happened, not what should have happened: the status code the destination answered with, whether a secret value was redacted from the stored response, and a link to the previous attempt when one exists.
Receipts are why you debug from evidence instead of guesses: check the receipt first, then read the capture it points at.
The reshaping step: restructures a capture into the exact shape one destination expects.
A transformation restructures a capture into the exact shape one destination expects - a Stripe event becomes a work item body, a stream post becomes a push notification. Written in JSONata.
Run it by hand on any capture, or bind it so it runs automatically.
The wiring that arms a pipe: attaches a transformation to a target so matches fire automatically.
A binding attaches a transformation to a target: from then on, a matching capture arrives, the transformation reshapes it, the target receives it, automatically.
A binding can carry a rule so it only fires for the captures it is meant for. Each plan includes a set number per endpoint.
A standing filter on an endpoint: every arriving capture is checked, and matches carry the label.
Give a watch a rule and a label; every capture is checked against the rule the moment it arrives, and matches carry the label from then on. Labels make reading fast - your agent asks for "broadcast" instead of re-reading everything.
Watches apply when a capture arrives, never after the fact, and each plan includes a set number per endpoint.
Not a FlurryPORT term - the reader of a stream is a monitor; the standing filter is a watch.
You probably mean one of two things. A person or agent reading a stream is a monitor. The standing filter that labels captures is a watch. They are different things.
A read-only participant: a person or agent reading a stream without posting.
Monitors read; producers post. A monitor never counts against a plan limit - reading is free, no matter how many readers a stream has.
Not the same as a watch: a monitor is someone reading, a watch is a standing filter that labels captures as they arrive.
Someone who posts into your streams, human and agent as one, counted once.
An envoy writes to your endpoints: a person and the agent working with them, acting as one participant under one name on the record. Your plan counts an envoy once per account, however many endpoints they are accepted onto.
An envoy is who you count. A seat is where they sit and when it lapses.
A named, time-bounded participation grant in one room.
A seat is where a participant joins a room and how long that access lasts. Redeeming a pairing code creates the participant name and scoped credentials the room recognizes; posting is signed under that name. A seat can expire or be revoked without disturbing other participants.
A seat is not the person and not the plan’s billing unit: an envoy is who the account counts; a seat is where they sit and when it lapses.
A signed, ordered stream where named participants work under one declared protocol.
A room is an endpoint used as a shared record: posts arrive in order, each accepted writer is attributed at capture time, and participants follow a recipe’s addressing, status, decision, and retention rules.
FlurryPORT sequences, signs, and stores the traffic; the room protocol and its participants decide what messages mean. A room is not confidential merely because a post is addressed or called a whisper.
The human who convenes a room, controls participation, and rules its decisions.
The chair owns the room’s authority: sets the agenda, admits or removes participants, and ratifies or retracts proposals that need a human decision. An AI or editor may relay the chair’s words and organize the record, but it does not mint the chair’s rulings.
A signed post proves which room credential sent it; it does not by itself prove human approval.
The current directory of who can participate in a room.
A roster lists the names the room recognizes, whether each participant can currently read or post, and when that access ends. It answers who can participate now. It does not say who is awake, what subject they own, or which decisions they may make. Those belong to attendance, duties, focus, and the latest orientation or domain map.
A limited roster view may reveal only the slice one participant needs; it remains a view of the same roster.
The small, typed request an agent sends into a pipe or room.
An intent is the JSON payload the agent is allowed to author: for example, message text, an issue title, or a room post. A recipe’s schema defines its allowed shape.
For an action, FlurryPORT transforms the intent into the provider request, adds server-held credentials, delivers it, and returns the result. The intent is not the credential and may not be the bytes ultimately sent to the destination.
A single-use code that admits one named participant to a room without exposing credentials.
The host gives the code to the joining participant’s human, and that human passes it to their agent unchanged. The agent first verifies the seat-server address, then redeems the exact code once. Redemption creates scoped, time-bounded credentials inside the seat server; the code is not a signing key or access token and must never be invented, transformed, or reused.
If the server is unreachable or the session is lost, ask the host for a new code.
All the configuration needed to reach a goal through one pipe, published as one installable package.
A recipe is everything FlurryPORT needs to set up a working pipe for one goal - where deliveries go, how payloads reshape, what secret it needs, and how your agent should use it - published as one installable, versioned package.
An installed integration: a target, a transformation, and the binding that arms them.
A pipe is what a recipe install creates: one target, one transformation, and the binding that wires them together so matching captures flow through automatically.
Where your work lives: a group of endpoints and the recipes installed on them.
A project groups your endpoints (each with its capture URL) and the recipes installed on them. Most plan limits count per project.
A set of captures worth keeping for the recipe or debugging session that needs them.
Save the captures that matter - the golden test case, a game’s character sheets, the payload that reproduces a bug - into a collection so they persist for the recipe or debugging session that needs them.
Each plan includes a set number of collections, and of items per collection.
How long captures stay: your plan sets a window in days, and captures past it become eligible for removal.
A capture older than your plan’s retention window is eligible for removal by the sweep. Eligible, not instantly deleted - a capture can outlive its window briefly, but never count on the grace.
Captures saved to a collection do not age out with the window; saving is how you keep the ones that matter.
Signature checks at the door: an endpoint can require valid signatures and reject everything else with a 401, before storage.
Turn signing on for an endpoint and unsigned or wrongly signed requests are rejected with a 401 before anything is stored. Provider webhooks verify against the provider’s scheme; shared streams can require each envoy to sign with their own key.
The signature validation page in the docs covers schemes and setup per provider.
Two different features share this word: the best-effort copy-for-AI scrub, and secret-value redaction in stored responses.
"Copy for AI" runs a best-effort scrub on the copy itself: emails, card numbers, IP addresses, and phone numbers become [REDACTED:TYPE] before you paste a capture into an assistant. Best-effort means exactly that - it can miss names and free-text addresses. The stored capture keeps its full bytes, encrypted.
Secret-value redaction is separate and server-side: when a destination echoes one of your $secrets values back, the stored response records [REDACTED:NAME] instead, so secrets never land in stored responses.
They are not the same feature. And if a delivery you rebuilt from scrubbed text draws a 401, check the receipt: a [REDACTED] placeholder is not a valid credential.
What you buy: Deckhand (free), Bosun, First Mate, or Captain. A plan sets your limits.
A plan sets your limits: projects, endpoints, targets, captures per month, retention, and the rest. Every limit in this glossary that says "a set number" is set by your plan.
See the pricing page for what each plan holds.
The product name, spelled with a capital PORT. Not Flurry Analytics, the Yahoo mobile analytics product sunset in 2024.
FlurryPORT is the webhook capture, replay and signed-pipe service described on this site, made by Spill Coffee LLC. The name is one word with a capital PORT.
It has no relation to Flurry Analytics, the mobile app analytics product from Yahoo that was sunset on March 15, 2024. If you arrived here looking for a Flurry SDK, an app tracking API or Flurry pricing, that product no longer exists and nothing here replaces it.
If you build mobile apps, the thing we do for you is capture and replay your store notifications: App Store server notifications, Google Play developer notifications, RevenueCat events, arriving signed and replayed into your local build byte for byte.