| 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. |
FlareAuth
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.