Portal operations

The Arbitex Cloud portal provides a unified interface for day-to-day administrative operations. This guide covers everything an org admin performs on a regular basis: configuring organizational settings, managing team members, authoring DLP rules, operating webhooks, reviewing audit logs, exporting data, and interpreting billing. For portal-wide features like global search, the analytics dashboard, dark mode, and accessibility settings, see Portal administration.

Portal roles and access model

Arbitex uses a two-tier organizational role model. Every user in an organization holds exactly one of these roles.

Capability	`org_member`	`org_admin`
View model catalog	Yes	Yes
View own conversation history	Yes	Yes
View provider health and latency	Yes	Yes
View routing fallback chains	Yes	Yes
Manage organization settings	No	Yes
Invite and deactivate members	No	Yes
Assign and change roles	No	Yes
Create and manage DLP rules	No	Yes
View all audit logs	No	Yes
Export audit logs and DLP events	No	Yes
Manage OAuth clients	No	Yes
Create and manage webhooks	No	Yes
Manage API keys (org-level)	No	Yes
View billing and invoices	No	Yes
Configure SSO and SCIM	No	Yes
Manage notification preferences	No	Yes
Manage groups and RBAC	No	Yes

Roles are assigned at org scope. There is no per-resource or per-group role differentiation beyond org_admin / org_member. If finer-grained access control is required, manage it through group membership and policy rules — see Groups and RBAC.

Organization settings management

Navigate to Settings → Organization to configure org-wide behavior.

Core settings fields

Setting	Type	Default	Description
`display_name`	string	—	Human-readable organization name shown in portal and emails
`timezone`	string	`UTC`	IANA timezone identifier used for report timestamps and scheduled exports
`session_timeout_minutes`	integer	`480`	Idle session duration before forced re-authentication (8 hours). Minimum: 15. Maximum: 1440.
`mfa_policy`	enum	`optional`	One of `off`, `optional`, or `required`. When `required`, users who have not enrolled in MFA cannot authenticate.
`allowed_ip_ranges`	array	`[]`	CIDR blocks permitted to access the portal. Empty list means all IPs are allowed.
`data_residency_region`	string	`us-east-1`	AWS region where data is stored. Contact support to change post-provisioning.
`enforce_sso`	boolean	`false`	When `true`, password login is disabled. All authentication must go through the configured SSO provider.

Updating settings via API

Settings can be read and updated through PUT /v1/orgs/{org_id}/settings. The full settings object must be provided (the endpoint is not PATCH-based).

curl -X PUT "https://api.arbitex.ai/v1/orgs/{org_id}/settings" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "Acme Corp",
    "timezone": "America/New_York",
    "session_timeout_minutes": 240,
    "mfa_policy": "required",
    "allowed_ip_ranges": ["10.0.0.0/8", "203.0.113.0/24"],
    "data_residency_region": "us-east-1",
    "enforce_sso": false
  }'

A successful response returns HTTP 200 with the updated settings object. Any field validation error returns HTTP 400 with a validation_errors array.

IP allowlist behavior

When allowed_ip_ranges is non-empty, any request from an IP not matching at least one CIDR block is rejected at the portal edge before authentication is attempted. This applies to both UI logins and API calls authenticated under the org.

MFA enforcement timeline

Setting mfa_policy to required does not immediately revoke active sessions. Sessions established before the policy change remain valid until they expire per session_timeout_minutes. New login attempts after the policy takes effect require MFA enrollment. Users who have not enrolled are prompted to enroll immediately after password authentication succeeds.

Member management lifecycle

Inviting members

Navigate to Settings → Members and click Invite Member.
Enter the invitee’s email address and select their role (org_admin or org_member).
Click Send Invite. The portal sends an invitation email containing a one-time link.
The invitee clicks the link, sets a password (or signs in via SSO), and their account is activated.

Invitation links expire after 7 days. If a link expires before the invitee accepts it, return to Settings → Members → Pending Invites and click Resend to generate a new link.

SCIM provisioning vs. manual invite

Method	Best for	Notes
Manual invite	Small teams, one-off additions	Requires admin action per user. Role assigned at invite time.
SCIM provisioning	IdP-managed lifecycle (Okta, Entra ID)	Automated create/update/deactivate via `POST /scim/v2/Users`. Role mapped from IdP group.

When SCIM is active, prefer provisioning over manual invites to keep the IdP as the source of truth. Manually invited users who are not in the IdP’s SCIM scope will not be deactivated automatically when they leave the organization — you must deactivate them manually.

The SCIM service provider configuration is available at:

GET https://api.arbitex.ai/scim/v2/ServiceProviderConfig

This endpoint returns the supported SCIM features, authentication schemes, and bulk operation limits. See SCIM provisioning for the full integration guide.

Role assignment and changes

Role changes take effect immediately. To change a member’s role:

Navigate to Settings → Members.
Click the member’s name to open their detail panel.
Use the Role dropdown to select the new role.
Click Save.

The member’s next API request or page load will reflect the new permissions without requiring re-authentication.

Deactivating members

Deactivation is a soft delete — the user record is retained for audit log integrity but the account is immediately inaccessible.

What happens on deactivation:

All active portal sessions are revoked immediately.
All personal API keys associated with the user are suspended (requests return HTTP 401).
The user’s name remains visible in historical audit log entries.
SCIM-provisioned users who are removed from the IdP are deactivated automatically.
Org-level API keys the user created are NOT deleted — they remain active under the org and must be reviewed separately.

To deactivate a member, navigate to Settings → Members, click the member’s name, and click Deactivate Account. Confirm the dialog. The member is immediately signed out.

DLP rule management

Data Loss Prevention rules intercept content in transit and apply configured actions (block, redact, flag, allow) based on pattern matching. Navigate to DLP → Rules to manage them.

Rule fields

Field	Type	Description
`name`	string	Human-readable label for the rule
`pattern`	string	Regular expression or named entity type pattern
`entity_type`	string	Semantic category (e.g., `CREDIT_CARD`, `SSN`, `EMAIL`, `CUSTOM`)
`action`	enum	`BLOCK`, `REDACT`, `FLAG`, or `ALLOW`
`priority`	integer	Evaluation order. Lower numbers are evaluated first.
`enabled`	boolean	Whether the rule participates in evaluation
`scope`	enum	`INPUT`, `OUTPUT`, or `BOTH` — which message direction the rule applies to

Rule priority ordering

Rules are evaluated in ascending priority order. The first matching rule whose action is BLOCK or REDACT terminates evaluation — subsequent rules are not checked for that content segment.

ALLOW rules can be used to create explicit exceptions. An ALLOW rule at priority 5 for an internal IP address pattern will prevent a REDACT rule at priority 10 from acting on that content.

Creating a rule in the portal UI

Navigate to DLP → Rules and click New Rule.
Enter a descriptive Name.
Select the Entity type from the dropdown or choose Custom to enter a raw regex pattern.
Set the Action (BLOCK, REDACT, FLAG, or ALLOW).
Set the Scope (INPUT, OUTPUT, or BOTH).
Assign a Priority value. Rules default to the next available multiple of 10.
Leave Enabled checked to make the rule active immediately, or uncheck to save it as a draft.
Click Save Rule.

Enabling and disabling rules

Toggle the Enabled switch on any rule row in the table to activate or deactivate it without deleting it. Disabled rules are shown with a dimmed row and are skipped during evaluation.

Known limitation: The cloud portal toggle currently hardcodes is_enabled: true and cannot disable a rule. This applies to both the individual toggle switch and the bulk actions menu. The Platform DLP rule toggle endpoint is planned but not yet implemented.

For bulk operations, select multiple rules using the checkboxes and use the Bulk Actions menu to enable or disable all selected rules at once.

Config export, import, and rollback

The DLP rule set can be exported and imported as JSON, enabling version control and cross-environment promotion.

Export current config:

curl "https://api.arbitex.ai/v1/orgs/{org_id}/config/backup" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

The response is a full configuration snapshot including all DLP rules, policy rules, and webhook configs with a snapshot_id and created_at timestamp.

Import config:

curl -X POST "https://api.arbitex.ai/v1/orgs/{org_id}/config/restore" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"snapshot_id": "snap_01HXY..."}'

The portal also stores automatic snapshots before any bulk operation (bulk enable/disable, import). Navigate to DLP → Rules → Config Snapshots to browse and restore from automatic snapshots. Snapshots are retained for 30 days. For the full backup and restore API reference, see Config backup and restore.

Webhook management

Webhooks deliver real-time event notifications from Arbitex to your external systems. Navigate to Settings → Webhooks to manage them.

Creating a webhook

Navigate to Settings → Webhooks and click Add Webhook.
Enter a descriptive Name for the endpoint.
Enter the URL — must be HTTPS. HTTP endpoints are rejected.
Select the Event types to subscribe to (see below).
The portal generates a Signing secret automatically. Store it securely — it is shown only once.
Click Save Webhook.

Event type categories

Category	Example events
`member.*`	`member.invited`, `member.activated`, `member.deactivated`, `member.role_changed`
`dlp.*`	`dlp.rule_created`, `dlp.rule_updated`, `dlp.detection_high_severity`
`api_key.*`	`api_key.created`, `api_key.revoked`
`outpost.*`	`outpost.health_degraded`, `outpost.health_recovered`, `outpost.cert_expiring`
`audit.*`	`audit.export_completed`, `audit.chain_verified`, `audit.chain_failed`
`billing.*`	`billing.usage_threshold_reached`, `billing.plan_limit_reached`
`webhook.*`	`webhook.delivery_failed`, `webhook.dlq_threshold_reached`

Subscribe to only the event types your system consumes. Broad subscriptions increase delivery volume and load on your endpoint.

Testing a webhook

After creating a webhook, click Test on the webhook row. The portal sends a synthetic test.ping event to the configured URL and displays the HTTP response code and latency. Use this to confirm connectivity before relying on the webhook in production.

Delivery behavior and retry policy

Arbitex considers a delivery successful when the endpoint returns HTTP 2xx within 10 seconds. Any other response (non-2xx, timeout, TLS error) is treated as a failure.

On failure, the delivery is retried using exponential backoff:

Attempt	Delay
1 (initial)	Immediate
2	1 second
3	2 seconds
4	4 seconds
5	8 seconds
6 (final)	16 seconds

After 6 attempts without a successful delivery, the event is moved to the dead letter queue (DLQ).

Dead letter queue monitoring

Navigate to Settings → Webhooks → {webhook name} → Dead Letter Queue to view queued failed deliveries. Each entry shows:

event_id — the event that failed delivery
event_type — the event type
failure_reason — the last HTTP response code or error message
failed_at — timestamp of the final failed attempt

To replay a DLQ entry, click Replay. To discard it, click Dismiss.

Delivery statistics

Each webhook row in the management table shows a statistics summary:

Field	Description
`success_count`	Total successful deliveries (lifetime)
`failure_count`	Total failed deliveries (lifetime)
`last_success_at`	Timestamp of the most recent successful delivery
`last_failure_at`	Timestamp of the most recent delivery failure
`dlq_depth`	Number of events currently in the dead letter queue

Resolving delivery failures

Symptom	Likely cause	Resolution
HTTP 404 on delivery attempts	Endpoint URL no longer valid	Update the webhook URL in Settings → Webhooks
TLS handshake error	Expired or self-signed certificate on endpoint	Renew the TLS certificate on the receiving server
HTTP 401 / 403	Endpoint requires authentication Arbitex cannot provide	Add a shared secret check to the endpoint, or use the signing secret header `X-Arbitex-Signature` for verification instead
HTTP 5xx	Endpoint server error	Investigate the receiving server; replay DLQ entries once fixed
Timeout	Endpoint processing takes more than 10 seconds	Make the endpoint accept and immediately acknowledge (HTTP 200), then process asynchronously

Notification center

The notification center surfaces system-generated alerts directly in the portal UI. Click the bell icon in the header to open it.

Notification categories

Category	Examples
Security	Failed login attempts (threshold exceeded), new API key created, MFA policy change
System	Outpost health degraded, outpost health recovered, TLS certificate expiring within 30 days
Billing	Usage approaching plan limit (80%, 95%), plan limit reached, invoice overdue
DLP	High-severity detection events, DLP rule change (bulk modify), config snapshot created

Notification preferences

Navigate to Settings → Notifications to configure delivery preferences per category.

Toggle	Behavior
In-app	Notification appears in the bell icon panel inside the portal
Email	Notification is also sent to the admin’s registered email address

Preferences are per-administrator — each org admin configures their own preferences independently. Changes take effect immediately for new events; existing unread notifications are not affected.

Managing notifications

Mark as read: Click any notification to mark it read. The unread count badge updates immediately.
Mark all as read: Use the Mark all read button at the top of the notification panel.
Dismiss: Hover a notification and click the X to dismiss it permanently. Dismissed notifications do not appear in the panel again.
Filter by category: Use the category tabs at the top of the notification panel to view only Security, System, Billing, or DLP notifications.

Notifications are retained in the panel for 90 days. Older entries are purged automatically.

Audit log operations

The audit log records every administrative action taken in your organization. Navigate to Audit → Logs.

Filtering audit events

The log view supports the following filters:

Filter	Description
Action type	Filter to a specific event type (see table below)
Date range	Start and end date/time in the org’s configured timezone
User	Filter to events performed by a specific member
IP address	Filter to events from a specific IP or CIDR block
Resource ID	Filter to events affecting a specific entity (user ID, rule ID, key ID)

Filters are combined with AND logic. Applying multiple filters narrows results.

Common audit event types

Event type	Description
`member.invited`	Admin sent an invitation to a new member
`member.activated`	Invitee accepted invite and activated their account
`member.deactivated`	Admin deactivated a member account
`member.role_changed`	Admin changed a member’s role
`dlp.rule_created`	New DLP rule created
`dlp.rule_updated`	Existing DLP rule modified
`dlp.rule_deleted`	DLP rule deleted
`api_key.created`	API key created (org-level or personal)
`api_key.revoked`	API key revoked
`settings.updated`	Organization settings updated
`webhook.created`	New webhook endpoint registered
`webhook.deleted`	Webhook endpoint deleted
`config.backup_created`	Configuration snapshot created
`config.restored`	Configuration snapshot restored
`sso.configured`	SSO configuration saved or updated
`audit.export_requested`	Admin requested an audit log export
`auth.login_success`	Successful authentication
`auth.login_failed`	Failed authentication attempt
`auth.mfa_enrolled`	User enrolled in MFA

HMAC chain fields

Each audit event includes cryptographic integrity fields that allow offline verification of log completeness:

Field	Description
`event_hash`	SHA-256 hash of this event’s canonical payload
`prev_hash`	`event_hash` of the immediately preceding event in the log chain
`hmac_signature`	HMAC-SHA256 signature over `event_hash + prev_hash`, signed with the org’s audit signing key
`sequence_number`	Monotonically increasing integer. Gaps indicate missing events.

To verify chain integrity, use the audit chain verification API:

curl "https://api.arbitex.ai/v1/orgs/{org_id}/audit/verify" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

For the full integrity verification guide, see Audit log verification.

Exporting audit logs

Exports are available in CSV or JSON format.

curl -X POST "https://api.arbitex.ai/v1/orgs/{org_id}/audit/export" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "format": "json",
    "start_at": "2026-02-01T00:00:00Z",
    "end_at": "2026-02-28T23:59:59Z",
    "event_types": ["dlp.rule_created", "dlp.rule_updated", "member.deactivated"]
  }'

The export runs asynchronously. The response includes an export_id. Poll GET /v1/orgs/{org_id}/audit/export/{export_id} for status. When status is completed, a download_url is provided. Download URLs expire after 1 hour.

Retention policy

Audit log entries are retained for 90 days by default. Retention can be extended to 365 days or 7 years for compliance tiers — contact support to adjust. Events older than the retention window are permanently deleted and cannot be recovered. Schedule regular exports to SIEM if long-term retention is required. See SIEM integration guide.

Data export

The data export system allows admins to extract operational data from Arbitex in bulk. Navigate to Settings → Data Export.

Exportable entity types

Entity type	Description
`members`	All org members including role, status, created_at, last_login_at
`dlp_events`	DLP detection events with severity, action taken, and content category
`audit_events`	Full audit log (same as audit log export, accessible here for convenience)
`analytics`	Aggregated usage analytics (request counts, token usage, model breakdown)
`oauth_clients`	OAuth client registrations and scopes
`webhooks`	Webhook endpoint configurations and delivery statistics
`groups`	Group definitions and member lists
`api_keys`	API key records (metadata only; key values are never exported)

Rate limits

Exports are rate-limited to 1 export per 60 seconds per organization across all entity types. Attempting a second export before the cooldown expires returns HTTP 429 with a Retry-After header.

Export formats

Both CSV and JSON are supported. Specify the format in the format field of the export request body.

CSV: One file per entity type. Column headers in the first row. Suitable for spreadsheet analysis.
JSON: Array of objects. Suitable for programmatic processing and SIEM ingestion.

Column reference: members export

Column	Description
`user_id`	UUID of the member
`email`	Email address
`display_name`	Full name
`role`	`org_admin` or `org_member`
`status`	`active` or `deactivated`
`mfa_enrolled`	`true` or `false`
`created_at`	ISO 8601 timestamp when the account was created
`last_login_at`	ISO 8601 timestamp of most recent successful authentication
`deactivated_at`	ISO 8601 timestamp of deactivation, if applicable

Column reference: dlp_events export

Column	Description
`event_id`	UUID of the DLP detection event
`detected_at`	ISO 8601 timestamp
`rule_id`	UUID of the DLP rule that triggered
`rule_name`	Name of the triggered rule
`entity_type`	Entity type category (e.g., `CREDIT_CARD`, `SSN`)
`action_taken`	`BLOCKED`, `REDACTED`, `FLAGGED`, or `ALLOWED`
`severity`	`LOW`, `MEDIUM`, or `HIGH`
`direction`	`INPUT` or `OUTPUT`
`user_id`	UUID of the user whose request triggered the detection
`model_id`	Model the request was routed to
`conversation_id`	UUID of the conversation, if applicable

Billing portal

Navigate to Settings → Billing to review plan status and invoices.

Plan summary

The top of the billing page shows the current plan summary:

Field	Description
`plan_name`	Subscription tier (e.g., Starter, Growth, Enterprise)
`seats_used` / `seats_total`	Current member count vs. seat limit
`api_calls_used` / `api_calls_total`	API requests used this billing period vs. period limit
`current_period_start`	Start of the current billing period
`current_period_end`	End of the current billing period

Usage bars

Each metered resource (seats, API calls, token usage) is displayed with a horizontal usage bar:

Color	Threshold	Meaning
Green	0–79%	Normal consumption
Yellow	80–94%	Approaching limit — consider reviewing usage or upgrading
Red	95–100%	Near or at limit — action required to avoid service interruption

When usage reaches 80% of any metered resource, a Billing notification is sent to all org admins (if billing notifications are enabled). A second notification fires at 95%.

Invoice history

The invoice table shows all billing periods:

Column	Description
`period`	Billing period covered by the invoice
`amount`	Total amount billed
`status`	`paid`, `pending`, or `overdue`
`invoice_pdf`	Download link for the PDF invoice

Invoices with overdue status indicate a payment failure. API access may be restricted if an invoice remains overdue for more than 7 days. Click Update Payment Method or contact your account manager.

Approaching limits

Situation	Recommended action
Seat limit approaching	Upgrade plan or deactivate inactive members
API call limit approaching	Review usage dashboard for high-volume consumers; consider upgrading plan
API call limit reached	Requests return HTTP 429. Upgrade plan immediately or contact sales for a temporary extension.
Invoice overdue	Update payment method in billing portal or contact support

For plan changes, click Upgrade Plan on the billing page. Enterprise plan inquiries go through Contact Sales.

Model catalog and routing

The model catalog and routing views are read-only observability surfaces. Full configuration is performed in the admin area — see Model routing configuration and Provider management.

Model catalog summary

Navigate to Models to view all models available to the organization. Each row shows: model name, model ID, provider, status (active/inactive), capabilities (streaming, vision, function calling), and cost per 1M tokens.

Use the provider filter tabs to narrow the list. The search box filters by model name or ID. Inactive models are visible but will not route requests.

Routing and fallback chains

Navigate to Routing → Fallback Chains to view the configured fallback order per model. Each model can have an ordered list of alternative models the gateway attempts if the primary fails. The gateway activates fallback routing when the primary provider’s circuit breaker opens (3 or more consecutive failures) or returns a 5xx response.

Provider health

Navigate to Routing → Provider Health to view per-provider health scores. The health score ranges from 0.0 (fully unavailable) to 1.0 (no failures in the current window). Circuit breaker states:

State	Meaning
Closed	Provider is healthy; all requests route normally
Open	Provider has failed 3+ consecutive checks; fallback routing is active
Half-open	Gateway is probing recovery; a single successful probe closes the circuit

Recovery is automatic. No manual intervention is required.

Latency monitor

Navigate to Monitoring → Latency to view response time percentiles per model over a selectable window (1 Hour, 24 Hours, 7 Days, 30 Days). The table shows p50, p95, p99, mean, request count, and a trend indicator comparing the current window to the previous equivalent window.

Color	Threshold	Meaning
Green	< 200 ms p95	Healthy latency
Yellow	200–499 ms p95	Elevated latency — monitor
Red	≥ 500 ms p95	Degraded latency — investigate

Troubleshooting reference

Common issues

Issue	Likely cause	Resolution
SSO login fails for all users	IdP configuration change or SAML certificate mismatch	Check IdP metadata URL; verify SAML signing certificate matches the one configured in Settings → SSO. See SSO configuration guide.
SSO login fails for one user	User not in IdP app assignment or attribute mapping missing	Check the user’s group membership in the IdP; verify the email attribute is mapped.
Webhook 404 errors	Endpoint URL is no longer valid	Update the webhook URL in Settings → Webhooks or delete the webhook if the integration is retired.
DLP rules not applying	Rules are disabled or priority conflict	Confirm rules are enabled (Enabled toggle is on). Check priority ordering — an `ALLOW` rule at a lower priority number may be suppressing a downstream `BLOCK` or `REDACT`.
Export rate limit hit (HTTP 429)	Multiple exports requested within 60-second window	Wait 60 seconds between export requests. Only one export per org can be in-flight at a time.
MFA lockout — user cannot authenticate	User lost access to MFA device	Admin can reset MFA enrollment for a specific user via the API: `DELETE /v1/orgs/{org_id}/users/{user_id}/mfa`. The user will be prompted to re-enroll on next login.
Session expired repeatedly	`session_timeout_minutes` set too low	Navigate to Settings → Organization and increase `session_timeout_minutes`. Minimum is 15; recommended minimum for admin users is 60.
API key requests returning 401	Key was revoked or user was deactivated	Check Settings → API Keys for key status. If the associated user was deactivated, their personal API keys are suspended.
Config restore failed	Snapshot ID invalid or snapshot expired	Snapshots expire after 30 days. Re-export the desired config and create a new snapshot.
Notification emails not arriving	Email notifications disabled or email server filtering	Check Settings → Notifications to confirm email toggle is on. Check spam filters; Arbitex sends from `[email protected]`.
High DLQ depth on webhook	Receiving endpoint is consistently unavailable or slow	Investigate the receiving server. Replay DLQ entries after the endpoint is healthy. If the endpoint is permanently decommissioned, delete the webhook.
Audit chain verification fails	Gap in audit event sequence numbers	Potential log tampering or export issue. Preserve the current log export immediately and contact support. Do not continue modifying the org until the chain is validated.