Declare the API path
For a multi-service app, add these entries tofloo.app.toml. This example assumes
your declared services are named web and api, both with public ingress.
/integrations/v1 and its endpoints; floo forwards
the full path unchanged. A FastAPI fixture:
floo redeploy --app <name> --rebuild with an admin-scoped floo credential to
apply it in dev, and release and promote reject the broadening while the policy
is on. Any separately configured infrastructure-review policy still applies.
Explicit multi-service routes replace the default path table on the app host,
service aliases, and verified custom domains. See Multi-service routing.
Create a consumer and a scoped key
Create a named consumer and a key scoped to the declared route:--app <name> to select
another app. --consumer accepts an ID or a case-insensitive name. The CLI uses
your floo API key; keep it separate from the app key you give the program.
Human mode prints only the one-time raw key on stdout; the shown-once notice,
key ID, prefix, and scopes go to stderr. Store the raw value directly in the
program’s secret store; it cannot be retrieved again. Do not paste it into a
chat or prompt, print it in logs, or put it in a URL or repository. Keep the
key ID for request-history queries and revocation.
To store a new key in another floo app without showing it in the terminal or
an agent transcript, pipe it to floo env set. Replace report-worker with the
app that will call the API:
--json, raw_key is redacted unless you pass the global
--reveal-secrets flag. The output sets contains_secrets: true in either case.
--scope is required and repeatable. Use --scope '*' only to grant every
scope. Scopes are exact-match labels, not
HTTP-method permissions: GET and POST under the same scoped route use the
same gate. Your application still owns operation and record-level permissions.
List consumers and key metadata without redisclosing the key:
Call the app
The program sends the app key asAuthorization: Bearer to the app’s public
URL, for example /integrations/v1/status, with no browser cookie.
The fixture returns {"ok": true} with status 200. Missing, malformed, revoked,
and wrong-app keys return 401. A valid key without the required scope returns
403; a per-key rate-limit rejection returns 429. floo strips the raw key before
forwarding the request and supplies verified consumer identity headers instead:
floo removes any
X-Floo-* header the caller sends, so these values always come
from the gateway. Sending an app key to the / browser route does not sign the
caller in.
Inspect requests by key
Use your floo API key, not the app key:next_cursor as cursor
and keep the same filters. total counts this page, not all matching requests.
The maximum page size is 500.
For a fixed interval, use timezone-aware ISO 8601 since and until values;
until is exclusive. URL-encode query values. The host filter distinguishes
app hostnames and environments. An expired or invalid cursor returns
REQUESTS_QUERY_ERROR; restart the query with the intended time range.
Verified keys remain attributable on scope and per-key rate-limit failures.
Unknown or invalid credentials are not assigned a key identity. Request bodies,
authorization headers, cookies, and query strings are not part of this history.
History is buffered asynchronously and retained for about seven days, so a
request takes time to appear. Buffer overflow or a process crash can lose
events: this is request visibility, not a lossless business-change audit log.
Revoke access
Revoke a key by its ID:HTTP reference
Use the management API athttps://api.getfloo.com with your floo operator
credential, kept separate from the app key you give the program. Substitute your
app and record IDs in these routes.
Create a named consumer:
id to create its key:
id and a one-time raw_key. Always
set scopes explicitly in HTTP requests; omitting them grants the wildcard default.
Inventory endpoints return metadata without redisclosing the key: