Quick start
This workflow creates a shared provider, creates an app, reads it, then disables it without losing configuration. Replace the placeholder origin with your central management origin and enable management access before making requests.
1. Prepare access
An operator enables LLMGATEWAY_MANAGEMENT_API_ENABLED=true on the central service. A verified tenant administrator or authorized Quilr operator opts the tenant in and issues a management key. See authentication.
For this workflow, the key needs read, providers:write, config:write and credentials:write.
export MANAGEMENT_ORIGIN='https://management.example.com'
export MANAGEMENT_KEY='<management-key>'
export PROVIDER_API_KEY='<provider-api-key>'
Keep secrets in your automation secret store. These example values are placeholders, not live credentials.
2. Create a shared provider
curl --request POST \
"$MANAGEMENT_ORIGIN/llmgateway/management/v1/providers" \
--header "Authorization: Bearer $MANAGEMENT_KEY" \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: support-provider-001' \
--data "{\"label\":\"Production OpenAI\",\"provider_name\":\"openai\",\"provider_settings\":{\"api_key\":\"$PROVIDER_API_KEY\"},\"selected_models\":[\"gpt-4.1-mini\"]}"
A 201 response returns provider metadata and credential-presence flags. Saving does not contact the provider. Use explicit testing when you want to verify connectivity or model access.
3. Create an app
curl --request POST \
"$MANAGEMENT_ORIGIN/llmgateway/management/v1/apps" \
--header "Authorization: Bearer $MANAGEMENT_KEY" \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: support-app-001' \
--data '{
"name": "Support Bot",
"provider_labels": ["Production OpenAI"],
"tags": ["production", "support"]
}'
{
"app": {
"name": "Support Bot",
"mode": "gateway",
"enabled": true,
"version": "app-v1",
"provider_labels": ["Production OpenAI"],
"tags": ["production", "support"],
"policy_authority": {"enabled": false, "active_revision": null}
},
"key": {
"key_id": "key_example",
"name": "Default",
"secret": "<new-gateway-key>",
"status": "active",
"expires_at": null
},
"warnings": [],
"request_id": "req_example"
}
The initial key is issued even when initial_key is omitted. Use the gateway credential for runtime calls. Keep using the management credential for configuration.
App creation does not create matching policy rules. If tenant-wide authority is enabled, matching rules govern traffic and a healthy no-match result is neutral. Review policy authority before sending production traffic.
4. Read the current version
curl --include \
"$MANAGEMENT_ORIGIN/llmgateway/management/v1/apps/Support%20Bot" \
--header "Authorization: Bearer $MANAGEMENT_KEY"
Use the returned ETag in updates. The example below assumes it is "app-v1"; use the actual value from your read.
5. Disable and re-enable
curl --request PATCH \
"$MANAGEMENT_ORIGIN/llmgateway/management/v1/apps/Support%20Bot" \
--header "Authorization: Bearer $MANAGEMENT_KEY" \
--header 'Content-Type: application/json' \
--header 'If-Match: "app-v1"' \
--data '{"enabled":false}'
This preserves the app, prompts, provider references and keys. After a gateway observes the change, newly admitted traffic is rejected for all app authentication modes. Existing requests finish normally.
To re-enable, read the latest ETag and PATCH {"enabled":true}. Keys that expired or were revoked while the app was disabled remain invalid. Propagation is asynchronous; the API does not promise an instantaneous global kill switch.