REST API

FlurryPORT has two HTTP surfaces and they do different jobs. The capture URL receives webhooks from providers and is documented on the webhook API reference. The REST API, this page, manages what happens around them: projects, endpoints, captures, replay targets, replay, collections, transformations and watches. If you are pointing a provider at us, you want the other page. If you are scripting FlurryPORT itself, you want this one.

https://api.flurryport.io/api/v1/...

Authentication

Browser session. The dashboard authenticates with a JWT cookie and sends a matching csrf header on every request. If you are calling the API from a signed-in browser session, this is what you already have. Some routes, marked "browser session only" below, accept nothing else.

Personal access tokens. For scripts, CI and anything running without a person present. Mint one in the app under Settings and send it as a bearer credential. No CSRF header is needed.

curl https://api.flurryport.io/api/v1/projects \
  -H "Authorization: Bearer $FLURRYPORT_TOKEN"

A token carries two scopes, both on by default when you mint it: read-only and redact PII. Both fail closed. A read-only token that hits a write route gets a 403 with a JSON body explaining that write access is granted by the account owner, never by the caller. A token of any scope that hits a route marked browser-only gets a 403 as well. Redaction masks emails, card numbers, phone numbers and IP addresses in capture reads, best effort; forwards to your own machine are untouched so signatures keep verifying.

Treat a token like a password. It is not a webhook secret and it is not a capture URL, and unlike both of those it can change your account.

Identifiers

Every id in a URL is a Base62 string, the same form the dashboard shows. Ids in JSON bodies are plain GUIDs. A malformed URL id answers 400 with { "Error": "Invalid identifier" }.

Projects

Endpoints

Captures

Listing captures

Each row carries the method, headers, query string, content type and length, remote IP, timestamps, provider hint and event type, your label, replay flags, a rejection reason if the capture was refused, and an opaque Cursor. With includeBody the row also carries Body, a UTF-8 text preview truncated to 4,096 characters; a binary payload leaves it null. The response ends with TotalCount and NextCursor.

To get a whole body, fetch the single capture. Its BodyBytes field is the full payload, base64 encoded, whatever the content type. That is the endpoint to use for anything you intend to verify a signature over.

Replay targets

Replay

A single replay takes { "CapturedRequestId", "ReplayTargetId" } and answers with the target’s status code, its response headers (secrets redacted), a body preview, the duration in milliseconds, and an Error field that is set instead when the delivery could not be attempted: a missing secret, an unverified domain, a transformation that failed, a connection that was refused. A target on your own machine is refused here with a message pointing at flurryport listen, because the server cannot reach localhost.

The queued forms return only execution ids. Poll the execution to learn the outcome; the same fields land there once the replay processor has run it.

Collections

The run body is the CI hook:

curl -X POST https://api.flurryport.io/api/v1/projects/{projectId}/endpoints/{endpointId}/collections/{collectionId}/run \
  -H "Authorization: Bearer $FLURRYPORT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"StopOnFailure": true, "DelayMs": 0}'

ReplayTargetId is optional; omitted, the run goes to every auto-forward target on the endpoint. StopOnFailure halts the sequence on the first non-2xx answer. DelayMs spaces the items out, up to 30,000. RetryUntilSuccess turns it into a run-until-200 (First Mate and up).

Transformations and bindings

Watches

Secrets and domains

Project secrets (/api/v1/projects/{projectId}/secrets) are browser-only end to end: a token can reference a secret by name in a target header but can never create, read or change one. Domain verification (/api/v1/domains) is the same, except that a token may list verified domains. See secrets.

Rate limits

Every request carrying a personal access token counts against a sliding window of 300 requests a minute per token. Past that the API answers 429 with no body and no Retry-After header, so back off for a few seconds and try again. The capture URL has its own limits, per endpoint and per plan, described on the plans and limits page.

Errors

Business errors use the application/problem+json shape: title is a stable machine code such as burst_limit_exceeded, detail is a sentence for a person, and validation failures add an errors map keyed by field.

A 404 is deliberately uninformative. A capture that has aged out under retention, a capture that never existed and a capture owned by another account all answer the same empty 404, so ids cannot be probed. If you need to know whether something once existed, keep your own record of the ids you were given.

What this API is not

It does not receive webhooks. Providers send to the capture URL, which has its own limits, its own signature validation and its own page: the webhook API reference. And it is not the whole product: rooms, recipes and the anonymous try-it session are driven through the CLI and MCP server, whose tools are the supported interface for those.