Actions, Feature Flags, and Pipes
New console modules let teams write custom Action hooks, manage Feature Flags, and configure Pipes for streaming data to external destinations.
From the changelog: Actions, Feature Flags, and Pipes modules
Authdog Team
Webhooks fire after authentication and cannot change the outcome. Product experiments need a switch that is not a deploy. Third-party data has to leave (or enter) under a connection you configured, not a one-off script. The console now has three environment-scoped modules for those jobs: Actions, Feature Flags, and Pipes.
This is the longer note behind the August 16 changelog entry.
How each module works
Actions are synchronous hooks in the authentication flow. Authdog POSTs a signed payload to your URL and waits. The hook can allow, deny, or enrich token claims. Triggers include pre_registration, pre_authentication, post_authentication, and pre_token_issuance. Fail-closed is the default if your endpoint times out or returns a bad body; fail-open is for enrichment that must never take down sign-in.
Feature Flags are environment-scoped keys (boolean, string, number, or json) with a default and optional targeting rules. Evaluation happens from your backend with an environment API secret. Rules match on subject attributes and optional percentage rollout. A flag is a delivery switch, not an authorization decision.
Pipes configure providers so application data can move to external destinations. In the console you register the provider credentials and endpoints for that environment. The public Pipes API then starts consent, stores tokens, and hands your backend a fresh access token when it needs to call the destination.
All three are per environment. A hook or flag in dev does not run in prod.
Set it up
In the Authdog console, select the project and environment:
- Actions — create a hook, set the trigger and URL, store the signing secret shown once, then use Test and Logs.
- Feature Flags — create a key, default, and rules. Evaluate from your backend; do not treat a client-side read as access control.
- Pipes — add a provider (client credentials, authorize and token URLs, scopes). Use the Pipes API from your server to start consent and fetch tokens.
Sidebar placement can differ by console build; the modules live at /dashboard/actions, /dashboard/feature-flags, and /dashboard/pipes when the environment is selected.
Trust boundaries
An Action signing secret is a webhook credential. Verify X-Authdog-Signature before you honor a deny or merge claims. Fail-open Actions must not be your only security check.
A feature-flag evaluation secret (adenv_…) is a server credential. Flags are not FGA or AuthZEN. Do not hide an admin route behind a flag and call that authorization.
Pipe provider secrets are encrypted at rest in Authdog. Your backend still holds the environment secret that mints user tokens for those destinations. Revoke a connection when the user should stop.
Actions change the auth outcome. Flags and Pipes do not.
Try it
Create a fail-closed pre_registration Action that denies a test domain, then attempt sign-up. Setup references: Actions, Feature flags, Pipes. The original release note is in the changelog.