flareauth

name: flareauth description: Operate a FlareAuth deployment through its Management API using Restish. Use this when an agent needs to inspect or change FlareAuth applications, connectors, users, roles, organizations, API resources, webhooks, security settings, branding, sign-in settings, or readiness through the standardized OpenAPI contract.

Use Restish against the FlareAuth Management API. The public Management API base path is:

/api/management

The OpenAPI contract is generated by the server and served at:

/api/management/openapi.json

Setup

Use a stable Restish profile name for the deployment you are operating:

restish api configure flareauth https://AUTH_HOST/api/management
restish api sync flareauth

If Restish cannot discover the spec from the base URL, point it at the explicit spec URL:

restish api configure flareauth https://AUTH_HOST/api/management --spec-file https://AUTH_HOST/api/management/openapi.json
restish api sync flareauth

Authentication

Prefer Restish's OAuth Authorization Code + PKCE flow. FlareAuth has a built-in public native client:

client_id: flareauth-cli
redirect_url: http://localhost:8484/callback
scopes: openid profile email offline_access management:read management:write

Start an auth header flow when you need a bearer token:

restish auth-header flareauth

Complete the browser sign-in as an administrator. Use the returned Bearer ... value with subsequent Restish commands:

restish flareauth list-applications -H "Authorization: Bearer TOKEN"

Do not use product OIDC client credentials for Management API automation. The Management API accepts an admin browser session or a bearer token issued to flareauth-cli; non-admin users receive 403.

Command Style

After api sync, prefer generated operation commands because they match the OpenAPI operationIds:

restish flareauth get-readiness -H "Authorization: Bearer TOKEN"
restish flareauth list-applications -H "Authorization: Bearer TOKEN"
restish flareauth get-application app_123 -H "Authorization: Bearer TOKEN"

When generated commands are awkward or unavailable, use Restish generic verbs with resource paths:

restish get flareauth/applications -H "Authorization: Bearer TOKEN"
restish get flareauth/applications/app_123 -H "Authorization: Bearer TOKEN"
restish post flareauth/applications -H "Authorization: Bearer TOKEN" < app.json
restish patch flareauth/applications/app_123 -H "Authorization: Bearer TOKEN" < patch.json
restish delete flareauth/applications/app_123 -H "Authorization: Bearer TOKEN"

Use -o json when another tool or script will consume the result.

Common Operations

Create an application:

restish flareauth create-application \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -o json <<'JSON'
{
  "name": "Customer Portal",
  "slug": "customer-portal",
  "clientType": "public_spa",
  "redirectUris": ["https://app.example.com/oidc/callback"],
  "firstParty": true,
  "trusted": true
}
JSON

Update an application:

restish flareauth update-application app_123 \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -o json <<'JSON'
{
  "name": "Customer Portal Updated"
}
JSON

Create a draft connector:

restish flareauth create-connector \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -o json <<'JSON'
{
  "slug": "google",
  "providerType": "social",
  "providerId": "google",
  "displayName": "Google",
  "enabled": false
}
JSON

Check deployment readiness:

restish flareauth get-readiness -H "Authorization: Bearer TOKEN" -o json

Guardrails

Always sync before operating a deployment you have not used recently.
Prefer resource nouns and real IDs from list/get responses; do not infer IDs from names.
System-managed applications such as flareauth-cli must not be deleted or modified.
Asset upload endpoints use multipart/form-data with a single file field.
Raw secrets are returned only once on creation or rotation; never expect list/detail responses to reveal secret material.
For large changes, read current state first, apply the smallest patch, then read back the resource to verify.