Config backup and restore

The config backup feature lets you export your entire Arbitex organization configuration as a JSON snapshot and import it into the same or a different organization. This covers DLP rules, policy packs, group settings, routing rules, quotas, and more — everything needed to fully reconstruct your governance configuration in a new environment.

Common use cases: disaster recovery, environment cloning (dev → staging → prod), configuration versioning, and org migration.

What is included

The export snapshot contains the following configuration domains:

Policy and DLP

Domain	Notes
`dlp_rules`	All DLP detection rules (regex, NER, GLiNER) including pattern, action tier, entity type, and group scope
`compliance_bundles`	Org-level and group-level compliance bundle assignments
`policy_templates`	Policy rule templates
`routing_rules`	Model routing rules
`content_filters`	Keyword block, topic block, and custom instruction filters

Access and quotas

Domain	Notes
`group_dlp_configs`	Per-group DLP detector overrides
`group_model_access`	Per-group model ALLOW/DENY rules
`group_compliance_bundles`	Per-group compliance bundle assignments
`quotas`	User and group token/request/cost limits
`ip_allowlist`	IP range allowlist entries

Infrastructure

Domain	Notes
`enterprise_entitlements`	Feature entitlement flags
`kill_switch_state`	Models/providers currently disabled via kill switch
`fallback_chains`	Model fallback chain configurations
`retention_policies`	Data retention settings per table
`org_metadata`	Organization-level settings

Integrations (export-only for reference)

Domain	Notes
`webhooks`	Webhook registrations — HMAC secrets are not exported
`alert_rules`	Threshold-based monitoring rules
`saml_idp_configs`	SAML IdP metadata — x.509 certificates are not exported
`model_catalog`	Active model configurations (reference data)

What is excluded

The following are never included in exports:

Excluded	Reason
Users and user accounts	User identities are environment-specific
Billing and invoices	Billing is tied to the specific organization account
Webhook HMAC secrets	Security-sensitive — must be re-entered after import
SAML x.509 certificates	Security-sensitive — must be re-uploaded after import
Audit log entries	Audit records are immutable history, not configuration
Conversation history	User data, not configuration

Exporting a configuration snapshot

Via the admin portal

Navigate to Settings > Configuration Backup.
Click Export Config.
The portal generates the snapshot and shows a preview of the export summary (counts for each domain).
Click Download JSON to save the snapshot file.

The download file is named arbitex-config-{org_id}-{date}.json.

Via API

GET /api/v1/admin/orgs/{org_id}/config/export
Authorization: Bearer $ADMIN_TOKEN

curl -s https://api.arbitex.ai/api/v1/admin/orgs/org_01abc123/config/export \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  | jq . > arbitex-config-backup.json

Response envelope:

{
  "schema_version": "2.0",
  "backup_version": "2026-03-10T16:00:00Z",
  "exported_at": "2026-03-10T16:00:00Z",
  "org_id": "org_01abc123",
  "config": {
    "dlp_rules": [...],
    "compliance_bundles": [...],
    "policy_templates": [...],
    "routing_rules": [...],
    "group_dlp_configs": [...],
    "group_model_access": [...],
    "quotas": { "user_quotas": [...], "group_quotas": [...] },
    "model_catalog": [...],
    "kill_switch_state": [...],
    "fallback_chains": [...],
    "webhooks": [...],
    "alert_rules": [...],
    "saml_idp_configs": [...],
    "ip_allowlist": [...],
    "retention_policies": [...],
    "org_metadata": {...}
  }
}

The export is written to the audit log under action = "config_export".

Importing a configuration snapshot

Via API

POST /api/v1/admin/orgs/{org_id}/config/import
Authorization: Bearer $ADMIN_TOKEN
Content-Type: application/json

<snapshot JSON>

curl -s -X POST https://api.arbitex.ai/api/v1/admin/orgs/org_01abc123/config/import \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d @arbitex-config-backup.json

Response:

{
  "org_id": "org_01abc123",
  "imported_at": "2026-03-10T17:00:00Z",
  "summary": {
    "dlp_rules": { "created": 14, "updated": 0, "skipped": 2 },
    "compliance_bundles": { "created": 3, "updated": 1, "skipped": 0 },
    "policy_templates": { "created": 6, "updated": 0, "skipped": 0 },
    "routing_rules": { "created": 2, "updated": 1, "skipped": 0 },
    "quotas": { "user_quotas": 8, "group_quotas": 3 }
  }
}

The summary reports how many records were created, updated, or skipped in each domain. Skipped records are those that already exist and are identical to the snapshot.

The import is written to the audit log under action = "config_import".

Import behavior

Existing records: If a record in the snapshot has the same ID as an existing record, it is updated.
New records: If the ID is not found, the record is created.
Conflicts: If a record exists with the same logical key (e.g., same DLP rule name) but a different ID, the import creates a second record. Review the summary and deduplicate manually if needed.
Partial imports: The import applies all domains in one transaction. If any domain fails validation, the entire import is rolled back and no changes are applied.

Schema version compatibility

The current schema version is 2.0. The import endpoint accepts snapshots at version 1.0 and 2.0. A snapshot from version 1.0 will not include the new v2.0 domains (group DLP configs, kill switch state, fallback chains, etc.); those domains are simply left unchanged during the import.

Version 2.0 snapshots cannot be imported into an endpoint running version 1.0 schema.

Disaster recovery workflow

Use the following procedure to restore an organization’s configuration after data loss:

Retrieve the most recent backup. Snapshots should be stored in your organization’s backup storage (S3, Azure Blob, or local archive). The download filename includes the export date.
Create a new organization (or verify the target organization is empty / in a known baseline state).

Import the snapshot:

curl -s -X POST \
  "https://api.arbitex.ai/api/v1/admin/orgs/$TARGET_ORG_ID/config/import" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d @arbitex-config-backup.json

Re-enter secrets. Webhook HMAC secrets and SAML x.509 certificates are not included in exports. Update each webhook’s secret and re-upload SAML certificates.
Verify the import summary. Check that the expected count of DLP rules, policy templates, and groups matches your pre-incident configuration.
Run a compliance bundle dry-run to confirm policy rules resolve correctly for key groups.

Recommended backup cadence: Export nightly using the API and store snapshots with at least 30-day retention. Automate this with a scheduled job:

#!/bin/bash
DATE=$(date +%Y-%m-%d)
curl -s "https://api.arbitex.ai/api/v1/admin/orgs/$ORG_ID/config/export" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  > "backups/arbitex-config-${ORG_ID}-${DATE}.json"

Environment cloning (dev → staging → prod)

Config backup is the recommended method for promoting a validated governance configuration from one environment to another.

Typical promotion flow:

Develop and test DLP rules and policy packs in your dev environment.

Export the dev configuration:

curl -s "https://dev-api.arbitex.ai/api/v1/admin/orgs/$DEV_ORG/config/export" \
  -H "Authorization: Bearer $DEV_TOKEN" > dev-config.json

Import into staging:

curl -s -X POST "https://staging-api.arbitex.ai/api/v1/admin/orgs/$STG_ORG/config/import" \
  -H "Authorization: Bearer $STG_TOKEN" \
  -H "Content-Type: application/json" \
  -d @dev-config.json

Validate in staging (compliance tests, DLP evaluate endpoint, policy simulator).
Promote to production using the same import step.

Note: User accounts, group memberships, and quotas are included in the snapshot. Review the quotas section before importing into production — you may want to edit quota values to production-appropriate limits before the import.

Version compatibility reference

Export schema	Can import to
1.0	1.0, 2.0
2.0	2.0 only

Upgrading from schema 1.0 to 2.0 is automatic — export from a 1.0 instance and import into a 2.0 instance. The missing v2.0 domains are ignored and left at their defaults.

Config backup and restore

What is included

What is excluded

Exporting a configuration snapshot

Via the admin portal

Via API

Importing a configuration snapshot

Via API

Import behavior

Schema version compatibility

Disaster recovery workflow

Environment cloning (dev → staging → prod)

Version compatibility reference

See also