Platform Administration

This guide covers platform administration operations available under the Admin panel. All endpoints require an admin-role Bearer JWT. Operations are tenant-scoped — admins see and modify only their own organization’s data.

For user and group management, see User and Group Management. For policy engine configuration, see Policy Engine Administration. For content categories, see Content Categories.

---

System Configuration

The system configuration registry controls platform-wide settings. Each key has a type, a category, and a resolution order: database override → environment variable → built-in default. Changes take effect immediately for most keys.

Viewing configuration

GET /api/v1/admin/config

Returns all configuration entries grouped by category, with each entry showing the current value and its source (database, environment, or default).

Response structure:

{
  "configs": {
    "security": [
      {
        "key": "jwt_access_token_expire_minutes",
        "value": 60,
        "type": "int",
        "source": "default",
        "editable": true
      }
    ],
    "application": [
      {
        "key": "app_version",
        "value": "2.14.0",
        "type": "string",
        "source": "environment",
        "editable": false
      }
    ]
  }
}

Updating a configuration value

PUT /api/v1/admin/config/{key}
Content-Type: application/json

{ "value": 30 }

The value is type-validated against the key’s registered type. An audit event config_changed is recorded with the key, old value, and new value.

Configuration reference

Application (read-only)

Key	Type	Description
app_name	string	Application display name
app_version	string	Current platform version
debug	boolean	Debug mode flag
database_url	string	Database connection string (masked in API response)
jwt_algorithm	string	JWT signing algorithm

Security

Key	Type	Range	Description
jwt_access_token_expire_minutes	int	5–1440	Access token lifetime in minutes (default: 60)
security_hsts_enabled	boolean	—	Send HSTS header on all responses
prompt_guard_enabled	boolean	—	Enable prompt injection guard
prompt_guard_log_level	enum	debug, info, warning, error	Prompt guard log verbosity
admin_recovery_enabled	boolean	—	Allow admin password recovery
self_service_recovery_enabled	boolean	—	Allow user self-service password recovery

Rate Limiting

Key	Type	Range	Description
rate_limit_requests_per_minute	int	1–10000	Standard user rate limit (default: 60 RPM)
rate_limit_admin_exempt	boolean	—	Exempt admin users from rate limiting

Audit

Key	Type	Description
default_summarizer_model	string	Model used for auto-title and summarization
audit_sinks	string	Comma-separated active sinks: db, jsonl, webhook

Conversation

Key	Type	Description
auto_title_enabled	boolean	Automatically generate conversation titles
auto_title_model	string	Model used for title generation

DLP

Key	Type	Description
dlp_entity_thresholds	string	JSON-encoded entity confidence thresholds

Email

Key	Type	Range	Description
smtp_host	string	—	SMTP server hostname
smtp_port	int	1–65535	SMTP server port
smtp_username	string	—	SMTP authentication username
smtp_password	string	—	SMTP password (masked in API response)
smtp_from_address	string	—	Sender email address for system emails

---

DLP Rule Administration

DLP rules define detection patterns evaluated by the DLP pipeline. Each rule targets a detector type, an entity type, and specifies an action tier. Rules support version tracking — every create, update, and delete operation is recorded with before/after snapshots.

For the DLP pipeline architecture, see DLP Overview. For group-level DLP overrides, see User and Group Management.

Rule fields

Field	Type	Description
detector_name	string	Human-readable detector label
detector_type	enum	Detection engine: regex, ner, or llm
entity_type	string	Entity being detected (e.g., credit_card, ssn, api_key)
action_tier	enum	Response action: log_only, redact, block, or prompt
enabled	boolean	Whether this rule is active
confidence_threshold	float	Minimum confidence score to trigger (default: 0.5)
config_json	object	Detector-specific configuration (see below)

Detector configuration by type:

Type	config_json fields
regex	{"pattern": "\\b\\d{3}-\\d{2}-\\d{4}\\b"} — regular expression pattern
ner	Entity labels for the NER model to extract
llm	LLM-based detection configuration

Action priority

When multiple rules match the same content, the highest-priority action wins:

Priority	Action	Behavior
4	block	Block the entire request
3	redact	Replace matched content with [REDACTED]
2	prompt	Warn the user and request confirmation
1	log_only	Record the finding without intervention
0	none	No action

API reference

Method	Path	Description
GET	/api/v1/admin/dlp-rules/	List all rules. Filter: enabled (bool), detector_type (string)
POST	/api/v1/admin/dlp-rules/	Create a rule with version tracking
GET	/api/v1/admin/dlp-rules/{rule_id}	Get a single rule
PUT	/api/v1/admin/dlp-rules/{rule_id}	Update a rule with version tracking
DELETE	/api/v1/admin/dlp-rules/{rule_id}	Delete a rule (pre-delete snapshot saved)
GET	/api/v1/admin/dlp-rules/{rule_id}/versions	Version history for a rule (newest first)
GET	/api/v1/admin/dlp-rules/available-patterns	List built-in patterns. Filter: category
GET	/api/v1/admin/dlp-rules/export	Export all rules as JSON
POST	/api/v1/admin/dlp-rules/import	Bulk import with conflict mode: skip, overwrite, or rename
POST	/api/v1/admin/dlp-rules/test	Dry-run test a pattern against sample text
POST	/api/v1/admin/dlp-rules/evaluate	Evaluate the full DLP chain for a text input

Creating a DLP rule

curl -X POST https://platform.arbitex.ai/api/v1/admin/dlp-rules/ \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "detector_name": "AWS Access Key",
    "detector_type": "regex",
    "entity_type": "aws_access_key",
    "action_tier": "block",
    "enabled": true,
    "confidence_threshold": 0.9,
    "config_json": {
      "pattern": "AKIA[0-9A-Z]{16}"
    }
  }'

Testing a rule before deployment

Use the test endpoint to dry-run a pattern against sample text without creating a rule:

curl -X POST https://platform.arbitex.ai/api/v1/admin/dlp-rules/test \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "pattern": "AKIA[0-9A-Z]{16}",
    "sample_text": "My AWS key is AKIAIOSFODNN7EXAMPLE for the prod account",
    "rule_type": "regex"
  }'

Evaluating the full DLP chain

Simulate how the entire DLP rule chain would evaluate a given input, including group-level overrides:

curl -X POST https://platform.arbitex.ai/api/v1/admin/dlp-rules/evaluate \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Please process card 4111-1111-1111-1111 for customer John Smith",
    "org_id": "your-org-uuid",
    "group_id": "optional-group-uuid",
    "user_id": "optional-user-uuid"
  }'

The response includes every matched rule, the final action decision, and a full decision trace showing evaluation order.

Built-in pattern categories

The available-patterns endpoint returns built-in detection patterns organized by category:

Category	Examples
secret	API keys, private keys, tokens, connection strings
pii	SSN, passport numbers, dates of birth
financial	Credit cards, IBAN, SWIFT/BIC, routing numbers
medical	DEA numbers, NPI, medical record numbers
infrastructure	IPv4/IPv6 addresses, database connection strings

Import and export

Export all rules as a JSON envelope:

curl https://platform.arbitex.ai/api/v1/admin/dlp-rules/export \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Response:

{
  "version": "1.0",
  "exported_at": "2026-03-15T12:00:00Z",
  "count": 42,
  "rules": [...]
}

Import rules with conflict resolution:

curl -X POST "https://platform.arbitex.ai/api/v1/admin/dlp-rules/import?mode=skip" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d @exported-rules.json

Mode	Behavior
skip	Skip rules that conflict with existing rules
overwrite	Replace existing rules with imported versions
rename	Import conflicting rules under a new name

Version history

Every create, update, and delete operation records a version entry:

curl https://platform.arbitex.ai/api/v1/admin/dlp-rules/{rule_id}/versions \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Each version entry includes:

Field	Description
change_type	create, update, or delete
changed_by	User ID of the admin who made the change
old_values	Previous field values (null for creates)
new_values	New field values (null for deletes)
changed_at	Timestamp of the change

Cloud portal toggle limitation

The Toggle platform DLP rule endpoint in the cloud portal (POST /v1/orgs/{org_id}/dlp-rules/platform/{rule_id}/toggle) currently always enables a rule — it does not flip the current state and cannot disable a rule. This is a known limitation of the current cloud portal implementation.

Workaround: To suppress enforcement without removing the rule, change the rule’s action to log via the platform admin API (PATCH /api/v1/admin/dlp-rules/{rule_id}). A rule with action: log records findings but does not block or redact traffic, providing the equivalent of a disabled enforcement state.

---

Model Registry (MRM)

The Model Registry implements Model Risk Management (MRM) aligned with OCC SR 11-7 guidelines. Every AI model used by the organization is registered, classified by risk tier, and tracked through a validation lifecycle. The registry provides governance controls for model approval, usage tracking, and inventory export.

Registry fields

Field	Type	Description
model_id	string	Model identifier (e.g., claude-sonnet-4-20250514)
provider	string	Provider name (e.g., anthropic, openai)
display_name	string	Human-readable model name
risk_tier	enum	unclassified, critical, high, medium, low
validation_status	enum	unclassified, under_review, approved, conditional, deprecated
owner	string	Responsible party for this model’s governance
description	string	Model description and use case
approved_use_cases	array	List of approved use case descriptions
restrictions	object	Constraints on model usage

Validation status lifecycle

Models progress through a state machine. Only these transitions are permitted:

                    ┌──────────────┐
          ┌────────►│ under_review │◄────────┐
          │         └──────┬───────┘         │
          │                │                 │
          │         ┌──────┴───────┐         │
          │    ┌───►│   approved   │───┐     │
          │    │    └──────────────┘   │     │
          │    │                       │     │
┌─────────┴──┐ │  ┌──────────────┐    │     │
│unclassified│ └──┤ conditional  ├────┘     │
└────────────┘    └──────┬───────┘          │
                         │                  │
                  ┌──────┴───────┐          │
                  │  deprecated  ├──────────┘
                  └──────────────┘

From	Allowed transitions
unclassified	→ under_review
under_review	→ approved, conditional, unclassified
approved	→ deprecated, conditional
conditional	→ approved, deprecated
deprecated	→ under_review

API reference

Method	Path	Description
GET	/api/v1/admin/models	List registry entries. Filter: risk_tier, validation_status, provider. Pagination: limit (max 500), offset
POST	/api/v1/admin/models	Register a model. Returns 409 if (model_id, provider) exists
GET	/api/v1/admin/models/{entry_id}	Get a single registry entry
PUT	/api/v1/admin/models/{entry_id}	Update registry fields
DELETE	/api/v1/admin/models/{entry_id}	Remove a registry entry
POST	/api/v1/admin/models/discover	Auto-discover unregistered models from audit log
POST	/api/v1/admin/models/{entry_id}/status	Transition validation status (state machine enforced)
GET	/api/v1/admin/models/{entry_id}/status/history	Approval log history (newest first)
GET	/api/v1/admin/model-inventory-export	Export inventory with usage stats (JSON or CSV)

Registering a model

curl -X POST https://platform.arbitex.ai/api/v1/admin/models \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model_id": "claude-sonnet-4-20250514",
    "provider": "anthropic",
    "display_name": "Claude Sonnet 4",
    "risk_tier": "medium",
    "owner": "AI Governance Team",
    "description": "General-purpose reasoning model",
    "approved_use_cases": ["document summarization", "code review"],
    "restrictions": {"no_pii": true, "max_context_window": 200000}
  }'

Auto-discovery

The discover endpoint scans the audit log for (model_id, provider) pairs that are not yet registered and creates draft entries with unclassified status:

curl -X POST https://platform.arbitex.ai/api/v1/admin/models/discover \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Use this after onboarding a new provider or periodically to catch models introduced through API usage that bypassed the registration workflow.

Status transitions

Transition a model through the validation lifecycle:

curl -X POST https://platform.arbitex.ai/api/v1/admin/models/{entry_id}/status \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "approved",
    "reason": "Completed security review and output quality assessment"
  }'

Every transition is recorded in the approval log with the old status, new status, reason, and the admin who performed it.

Inventory export

Export the full model inventory with 30-day and 90-day usage statistics:

# JSON format
curl "https://platform.arbitex.ai/api/v1/admin/model-inventory-export?format=json" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# CSV format (downloads as model-inventory-YYYY-MM-DD.csv)
curl "https://platform.arbitex.ai/api/v1/admin/model-inventory-export?format=csv" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -o model-inventory.csv

Export includes: model_id, provider, display_name, risk_tier, validation_status, owner, description, approved_use_cases, restrictions, created_at, updated_at, usage_30d, usage_90d, last_used_at.

Filter exports by risk tier or validation status:

curl "https://platform.arbitex.ai/api/v1/admin/model-inventory-export?format=csv&risk_tier=critical" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

---

Routing Rules

Routing rules define condition-based request routing independent of fallback chains. Rules are evaluated by priority (lower number = higher priority) and can route requests based on user groups, content patterns, providers, models, and other request properties.

For fallback chain configuration, see Model Routing Configuration.

Rule fields

Field	Type	Description
name	string	Human-readable rule name
priority	integer	Evaluation order (lower = higher priority, default: 100)
conditions	array	List of condition objects: {field, operator, value}
action	object	Routing action to apply when conditions match
enabled	boolean	Whether this rule is active

API reference

Method	Path	Description
GET	/api/v1/admin/routing-rules/	List rules ordered by priority (ascending)
GET	/api/v1/admin/routing-rules/{rule_id}	Get a single rule
POST	/api/v1/admin/routing-rules/	Create a routing rule
PUT	/api/v1/admin/routing-rules/{rule_id}	Update a rule (partial update)
DELETE	/api/v1/admin/routing-rules/{rule_id}	Delete a rule

Creating a routing rule

curl -X POST https://platform.arbitex.ai/api/v1/admin/routing-rules/ \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Route compliance team to GPT-4o",
    "priority": 10,
    "conditions": [
      {"field": "user_group", "operator": "in", "value": ["compliance-team"]},
      {"field": "provider", "operator": "eq", "value": "openai"}
    ],
    "action": {"route_to_model": "gpt-4o"},
    "enabled": true
  }'

---

Model Rate Limits

Per-model rate limits control requests per minute (RPM) and tokens per minute (TPM) for individual models. Models without a custom configuration use tier-based defaults. Changes take effect immediately — the in-memory rate limiter cache is updated on every write.

API reference

Method	Path	Description
GET	/api/v1/admin/rate-limits	List all configured limits plus tier-based defaults
PUT	/api/v1/admin/rate-limits/{model_id}	Create or update a rate limit
DELETE	/api/v1/admin/rate-limits/{model_id}	Remove custom config (reverts to tier defaults)

Default rate limits

Models with built-in defaults when no custom configuration exists:

Model	Default RPM	Default TPM
claude-sonnet-4-20250514	Tier default	Tier default
claude-opus-4-20250514	Tier default	Tier default
gpt-4o	Tier default	Tier default
gpt-4o-mini	Tier default	Tier default
gemini-pro	Tier default	Tier default
gemini-flash	Tier default	Tier default
o3	Tier default	Tier default
o4-mini	Tier default	Tier default

Configuring a rate limit

curl -X PUT https://platform.arbitex.ai/api/v1/admin/rate-limits/gpt-4o \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rpm_limit": 120,
    "tpm_limit": 500000,
    "enabled": true
  }'

The response from the list endpoint includes a source field indicating whether each limit is CUSTOM (database-configured) or DEFAULT (tier-based).

To revert a model to its tier default, delete the custom configuration:

curl -X DELETE https://platform.arbitex.ai/api/v1/admin/rate-limits/gpt-4o \
  -H "Authorization: Bearer $ADMIN_TOKEN"

---

Kill Switch

The kill switch provides emergency controls to disable providers or individual models. When activated, the gateway blocks all requests to the disabled entry with a 503 error. The kill switch state is persisted to the database and survives restarts.

The kill switch is separate from the is_active catalog flag on model configurations. The catalog flag is for routine model management; the kill switch is for emergency rapid disable.

Viewing kill switch state

# All providers with per-model state
GET /api/v1/admin/kill-switch/providers

# Single model state
GET /api/v1/admin/kill-switch/models/{model_config_id}

Disabling a provider

Disables all models for the specified provider:

curl -X POST https://platform.arbitex.ai/api/v1/admin/kill-switch/providers/openai/disable \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reason": "security_event"}'

Reason values: maintenance, cost_runaway, security_event, other

Disabling a single model

curl -X POST https://platform.arbitex.ai/api/v1/admin/kill-switch/models/{model_config_id}/disable \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reason": "maintenance"}'

Re-enabling

# Re-enable all models for a provider
POST /api/v1/admin/kill-switch/providers/openai/enable

# Re-enable a single model
POST /api/v1/admin/kill-switch/models/{model_config_id}/enable

No request body required for enable operations.

Audit trail

Every kill switch operation writes an audit event:

Event	Metadata
kill_switch_disable	target, model_config_id, reason, scope ("provider" or "model")
kill_switch_enable	target, model_config_id, scope

Kill switch API summary

Method	Path	Description
GET	/api/v1/admin/kill-switch/providers	List all providers with kill switch state
POST	/api/v1/admin/kill-switch/providers/{provider}/disable	Disable all models for a provider
POST	/api/v1/admin/kill-switch/providers/{provider}/enable	Re-enable all models for a provider
GET	/api/v1/admin/kill-switch/models/{model_config_id}	Get kill switch state for a model
POST	/api/v1/admin/kill-switch/models/{model_config_id}/disable	Disable a single model
POST	/api/v1/admin/kill-switch/models/{model_config_id}/enable	Re-enable a single model

---

Usage Analytics

The usage analytics API provides organization-level consumption data: current period summary, historical rollups, per-model breakdowns, and usage alerts.

API reference

Method	Path	Description
GET	/api/v1/admin/usage/summary	Current period usage summary
GET	/api/v1/admin/usage/history	Cursor-paginated rollup history
GET	/api/v1/admin/usage/by-model	Per-model usage breakdown
GET	/api/v1/admin/usage/alerts	Paginated usage alerts

Current period summary

curl https://platform.arbitex.ai/api/v1/admin/usage/summary \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Response:

{
  "org_id": "uuid",
  "plan_tier": "enterprise",
  "request_count": 15420,
  "input_tokens": 8234100,
  "output_tokens": 2156300,
  "cost_estimate": 127.45,
  "limit": 500000,
  "period_start": "2026-03-01T00:00:00Z",
  "period_end": "2026-03-31T23:59:59Z",
  "percentage_used": 3.08,
  "warning_level": null
}

The warning_level field is null when usage is normal, or one of warning_80, warning_95, limit_reached when thresholds are crossed.

Usage history

Cursor-paginated rollup data with configurable granularity:

curl "https://platform.arbitex.ai/api/v1/admin/usage/history?granularity=daily&limit=30" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Query parameters:

Parameter	Type	Description
granularity	enum	hourly, daily, or monthly
cursor	string	ISO 8601 timestamp for pagination
limit	integer	Results per page (1–90)

Per-model breakdown

curl "https://platform.arbitex.ai/api/v1/admin/usage/by-model?period_start=2026-03-01&period_end=2026-03-15&granularity=daily" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Returns aggregated usage from model_breakdown data in rollup records, showing per-model request counts, token volumes, and cost estimates.

Usage alerts

curl "https://platform.arbitex.ai/api/v1/admin/usage/alerts?limit=50" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Alert type	Trigger
warning_80	Usage reached 80% of period limit
warning_95	Usage reached 95% of period limit
limit_reached	Usage reached 100% of period limit

---

OAuth M2M Client Administration

OAuth machine-to-machine (M2M) clients enable programmatic API access without user credentials. Clients authenticate via client_credentials grant and receive RS256-signed JWTs.

For the token endpoint and OAuth flows, see OAuth Client Management.

API reference

Method	Path	Description
POST	/api/v1/admin/oauth-clients/	Create a client. Returns client_secret in plaintext (shown once)
GET	/api/v1/admin/oauth-clients/	List clients with pagination
GET	/api/v1/admin/oauth-clients/{client_id}	Get a single client (secret not included)
PUT	/api/v1/admin/oauth-clients/{client_id}	Update client settings
DELETE	/api/v1/admin/oauth-clients/{client_id}	Hard delete (permanently revokes credentials)
POST	/api/v1/admin/oauth-clients/{client_id}/rotate-secret	Rotate secret with grace period

Creating a client

curl -X POST https://platform.arbitex.ai/api/v1/admin/oauth-clients/ \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "CI Pipeline",
    "scopes": ["audit:read", "dlp:read"],
    "rate_limit_tier": "standard",
    "token_lifetime_seconds": 3600
  }'

Client fields:

Field	Type	Description
name	string	Client display name
scopes	array	Granted scopes (see scope reference below)
rate_limit_tier	enum	standard, premium, or unlimited
token_lifetime_seconds	integer	Token validity (max 86400 = 24 hours)

Rate limit tiers

Tier	Description
standard	Default rate limiting
premium	Elevated limits for high-throughput integrations
unlimited	No rate limiting (use with caution)

Secret rotation

Rotate a client secret with a grace period where the previous secret remains valid:

curl -X POST https://platform.arbitex.ai/api/v1/admin/oauth-clients/{client_id}/rotate-secret \
  -H "Authorization: Bearer $ADMIN_TOKEN"

The response includes the new client_secret in plaintext (shown once). The previous secret remains valid for the grace period (default: 3600 seconds / 1 hour), allowing integrations to update credentials without downtime.

---

MFA and Passkey Policy

Organization-level policies control MFA and passkey enforcement across all users.

MFA policy

# View current MFA policy
GET /api/v1/admin/org/mfa-policy

# Update MFA policy
PUT /api/v1/admin/org/mfa-policy
{ "enforcement_level": "required" }

Level	Behavior
off	MFA not enforced; users may optionally enable it
optional	Users are encouraged but not required to enable MFA
required	All users must complete MFA to access sensitive endpoints

When set to required, requests to sensitive endpoints (admin operations, API key management, SAML configuration, policy management, MFA setup/disable) without mfa_verified=true in the JWT receive HTTP 403 with X-MFA-Required: true header.

The MFA enforcement cache is cleared immediately when the policy is updated. Changes take effect within 60 seconds across all platform instances.

Admin MFA management

Admins can force-disable MFA for a specific user (e.g., locked out of authenticator):

DELETE /api/v1/admin/users/{user_id}/mfa

This clears the user’s TOTP secret, backup codes, and mfa_enabled flag. An audit event auth.mfa_disabled is recorded with the admin’s identity.

---

SAML IdP Administration

Manage SAML 2.0 Identity Provider configurations for SSO integration.

For SAML SSO setup and login flow details, see SAML SSO.

API reference

Method	Path	Description
POST	/api/v1/admin/saml/idp	Create an IdP configuration
GET	/api/v1/admin/saml/idp	List all IdP configurations (newest first)
GET	/api/v1/admin/saml/idp/{idp_id}	Get a single IdP
PUT	/api/v1/admin/saml/idp/{idp_id}	Update an IdP configuration
DELETE	/api/v1/admin/saml/idp/{idp_id}	Delete an IdP (prevents further SAML logins via this IdP)

IdP configuration fields

Field	Type	Required	Description
name	string	Yes	Display name for this IdP
entity_id	string	Yes	SAML entity ID (must be unique)
sso_url	string	Yes	IdP SSO endpoint URL
slo_url	string	No	IdP Single Logout URL
x509_cert	string	Yes	IdP signing certificate (PEM format)
attribute_mapping	object	No	Maps SAML attributes to platform fields
is_active	boolean	Yes	Whether this IdP is enabled for login

Creating an IdP

curl -X POST https://platform.arbitex.ai/api/v1/admin/saml/idp \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Corporate Okta",
    "entity_id": "https://sso.example.com/saml/metadata",
    "sso_url": "https://sso.example.com/saml/sso",
    "slo_url": "https://sso.example.com/saml/slo",
    "x509_cert": "-----BEGIN CERTIFICATE-----\nMIID...\n-----END CERTIFICATE-----",
    "attribute_mapping": {
      "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
      "username": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
      "groups": "http://schemas.xmlsoap.org/claims/Group"
    },
    "is_active": true
  }'

---

IP Allowlist

The IP allowlist restricts API access to specific CIDR ranges. When entries exist, requests from IPs outside the allowlist are blocked. Changes take effect immediately — the middleware cache is cleared on every create, update, or delete.

For detailed configuration, see IP Allowlist.

API reference

Method	Path	Description
GET	/api/v1/admin/ip-allowlist/	List all entries (newest first)
GET	/api/v1/admin/ip-allowlist/{entry_id}	Get a single entry
POST	/api/v1/admin/ip-allowlist/	Create an entry
PUT	/api/v1/admin/ip-allowlist/{entry_id}	Update an entry
DELETE	/api/v1/admin/ip-allowlist/{entry_id}	Delete an entry

Adding an IP range

curl -X POST https://platform.arbitex.ai/api/v1/admin/ip-allowlist/ \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "ip_range": "10.0.0.0/8",
    "description": "Corporate VPN range",
    "is_active": true
  }'

---

Admin Session Management

Admins can view and terminate active user sessions.

Method	Path	Description
GET	/api/v1/admin/sessions	List active sessions. Filter: user_id
DELETE	/api/v1/admin/sessions/{session_id}	Force-logout a single session
DELETE	/api/v1/admin/users/{user_id}/sessions	Force-logout all sessions for a user

Force-logout blacklists the session’s JWT (preventing further use) and records an auth.session_force_logout audit event.

---

See also

• User and Group Management — User invites, group CRUD, membership, DLP overrides, model access
• Policy Engine Administration — Policy packs, rules, chain configuration, simulation
• Content Categories — Category taxonomy, keyword classification, org overrides
• DLP Overview — 5-tier DLP pipeline architecture
• Model Routing Configuration — Fallback chains and health-based routing
• Admin Operations — Alerts, retention policies, quotas
• Audit Log — HMAC chain verification, SIEM integration