Cloud Portal Billing & Usage

The Cloud Portal billing dashboard gives organization administrators a real-time view of API consumption, DLP scan volume, and data throughput against their current plan limits. This guide explains how to read the billing dashboard, interpret usage metrics, navigate monthly history, export usage data, and manage plan upgrades or downgrades.

---

1. Billing Dashboard Overview

The billing dashboard is located at /portal/billing. It opens to a summary view for the current billing period showing how much of each plan quota has been consumed and whether any overage thresholds have been crossed.

Accessing the Dashboard

Navigate to Settings → Billing & Usage in the portal sidebar, or go directly to /portal/billing. You must hold the org_admin or billing_viewer role to view this page.

Current Period Usage Summary

The top section of the dashboard shows three primary usage metrics for the current billing period:

• API calls — total requests proxied through the Arbitex platform or any connected outpost.
• DLP scans — total content inspections executed against the DLP policy chain, including policy simulations.
• Data processed — total payload bytes (request plus response) processed by the platform, displayed in GB.

Each metric is shown as a progress bar with the current value, the plan limit, and a usage percentage. For example:

API Calls       42,310 / 100,000   42.3%  ████████░░░░░░░░░░░░
DLP Scans       18,750 / 50,000    37.5%  ███████░░░░░░░░░░░░░
Data Processed   38.2 / 100 GB     38.2%  ████████░░░░░░░░░░░░

The billing period start and end dates are shown above the progress bars so it is clear how much time remains in the current period.

Overage Alerts

When usage approaches or exceeds plan limits, the dashboard surfaces overage alerts inline with each metric. Alerts are also delivered as portal notifications (see Portal Notifications).

Alert thresholds fire at the following usage percentages by default:

Threshold	Level	Portal Treatment
80%	Warning	Yellow badge on progress bar, notification generated
90%	High	Orange badge on progress bar, notification generated
100%	Exceeded	Red badge, enforcement behavior depends on plan

Caution

When a plan limit is reached, the platform may begin rejecting or throttling requests depending on your plan configuration. Enterprise plans can be configured with soft overage allowances. Contact support if you need overage terms adjusted.

Billing Usage API

Programmatic access to the current period usage summary is available via:

GET /v1/orgs/{org_id}/billing/usage

Required role: org_admin or billing_viewer

Example response:

{
  "current_period": {
    "start_date": "2026-03-01",
    "end_date": "2026-03-31"
  },
  "metrics": [
    {
      "metric_name": "api_calls",
      "current_value": 42310,
      "plan_limit": 100000,
      "usage_percent": 42.31,
      "unit": "calls"
    },
    {
      "metric_name": "dlp_scans",
      "current_value": 18750,
      "plan_limit": 50000,
      "usage_percent": 37.50,
      "unit": "scans"
    },
    {
      "metric_name": "data_processed",
      "current_value": 41021836800,
      "plan_limit": 107374182400,
      "usage_percent": 38.20,
      "unit": "bytes"
    }
  ],
  "overage_alerts": [
    {
      "metric_name": "api_calls",
      "threshold_percent": 80,
      "triggered": false,
      "message": "API call usage is within normal range."
    },
    {
      "metric_name": "dlp_scans",
      "threshold_percent": 80,
      "triggered": false,
      "message": "DLP scan usage is within normal range."
    },
    {
      "metric_name": "data_processed",
      "threshold_percent": 80,
      "triggered": false,
      "message": "Data processed usage is within normal range."
    }
  ]
}

BillingUsageResponse Schema

Field	Type	Description
current_period	object	Billing period boundaries.
current_period.start_date	string (YYYY-MM-DD)	First day of the current billing period.
current_period.end_date	string (YYYY-MM-DD)	Last day of the current billing period.
metrics	array	One entry per tracked usage metric.
metrics[].metric_name	string	Metric identifier: api_calls, dlp_scans, data_processed.
metrics[].current_value	number	Consumed quantity in the metric’s native unit.
metrics[].plan_limit	number	Maximum allowed quantity for the current billing period.
metrics[].usage_percent	float	(current_value / plan_limit) * 100, rounded to two decimal places.
metrics[].unit	string	Human-readable unit label: calls, scans, or bytes.
overage_alerts	array	One entry per metric, indicating whether an alert threshold has been crossed.
overage_alerts[].metric_name	string	Which metric this alert covers.
overage_alerts[].threshold_percent	number	The configured threshold that triggers this alert (default: 80).
overage_alerts[].triggered	bool	true when usage_percent >= threshold_percent.
overage_alerts[].message	string	Human-readable status message.

---

2. Plan Tiers

Viewing Your Current Plan

The billing dashboard shows your organization’s current plan name, tier, billing cycle, and renewal date in the Plan Details card at the top right of the /portal/billing page.

To retrieve plan details programmatically:

GET /v1/orgs/{org_id}/plan

Required role: org_admin or billing_viewer

Example response:

{
  "plan_name": "Team",
  "plan_tier": "team",
  "billing_cycle": "annual",
  "renewal_date": "2027-01-01",
  "features": [
    "api_calls_100k_per_month",
    "dlp_scans_50k_per_month",
    "data_processed_100gb_per_month",
    "outpost_nodes_3",
    "rbac_full",
    "audit_retention_90_days",
    "sso_saml",
    "sla_99_5_percent",
    "support_priority"
  ]
}

PlanResponse Schema

Field	Type	Description
plan_name	string	Display name of the active plan (e.g., "Team").
plan_tier	string	Machine-readable tier identifier. See values below.
billing_cycle	string	monthly or annual. Annual plans are billed once per year.
renewal_date	string (YYYY-MM-DD)	Date on which the current plan term renews or expires.
features	array[string]	List of feature keys enabled on this plan.

plan_tier values:

Value	Display Name
dev_free	Dev Free
dev_pro	Dev Pro
team	Team
smb	SMB
enterprise	Enterprise

Plan Feature Matrix

The following table shows the resource limits and features included at each plan tier:

Feature	Dev Free	Dev Pro	Team	SMB	Enterprise
API calls/month	1,000	10,000	100,000	500,000	Custom
DLP scans/month	500	5,000	50,000	250,000	Custom
Data processed	1 GB	10 GB	100 GB	500 GB	Custom
Outpost support	—	1 node	3 nodes	10 nodes	Unlimited
RBAC roles	Basic	Basic	Full	Full	Full + custom
Audit retention	7 days	30 days	90 days	180 days	365 days
SSO / SAML	—	—	Yes	Yes	Yes
SLA	—	—	99.5%	99.9%	99.95%
Support	Community	Email	Priority	Dedicated	TAM

Tip

The Dev Free and Dev Pro tiers are intended for evaluation and development. They share the same RBAC model but are limited to basic role assignments. For production deployments requiring fine-grained access control, select Team or higher.

---

3. Usage Metrics Explained

Understanding exactly what counts toward each metric helps you model costs accurately and avoid unexpected quota exhaustion.

API Calls

Every proxied request that passes through the Arbitex platform or an outpost node counts as one API call. This includes:

• Requests sent directly to the Arbitex Platform API.
• Requests routed through an outpost proxy.
• Internal health-check or liveness probe requests do not count.
• Requests that are blocked by a DLP policy still count as an API call — the request was received and processed.

There is no minimum payload size for an API call to count. A single-character request counts the same as a large multi-turn conversation.

DLP Scans

Each content inspection executed against the DLP policy chain counts as one DLP scan. This includes:

• Live policy enforcement on proxied requests.
• Simulated policy evaluations via POST /policy-chain/simulate.
• Re-evaluation triggered by policy chain updates on cached content.

Tip

DLP simulations via /policy-chain/simulate count toward the DLP scan quota. If you are running automated policy testing pipelines, account for simulation volume when projecting monthly DLP scan consumption.

Data Processed

Data processed measures the total byte volume of request and response payloads processed by the platform. Both directions count:

• Request payload — the message body sent to the upstream AI provider.
• Response payload — the model response returned to the client.

Data processed is measured in bytes internally and displayed in GB in the portal (1 GB = 1,073,741,824 bytes). The data_processed metric in the API response uses raw bytes.

Large multimodal requests (images, documents) contribute more bytes per request than text-only prompts. If your workload includes vision or document-processing use cases, monitor data processed usage closely.

Quota Reset Timing

All three metrics — API calls, DLP scans, and data processed — reset to zero at the start of each billing period. The reset date is current_period.start_date in the BillingUsageResponse.

For monthly billing cycles, the reset occurs at 00:00 UTC on the first day of each calendar month. For annual billing cycles, the reset occurs on the annual anniversary of the plan start date. The portal displays the next reset date in the Plan Details card.

---

4. Usage History and Monthly Breakdown

Portal History View

The billing history page is located at /portal/billing/history. It shows:

• A month selector (calendar dropdown) to navigate to any month in the past 12 months.
• A daily bar chart showing API calls, DLP scans, and data processed per day across the selected month.
• A running totals table showing the month-to-date cumulative total for each metric.
• A summary row at the bottom of the table showing the full-month total.

Months with no activity are still accessible from the month selector but show empty charts and zero totals.

Usage History API

To retrieve daily breakdowns programmatically:

GET /v1/orgs/{org_id}/billing/usage/history?month=YYYY-MM

Query parameters:

Parameter	Type	Required	Description
month	string	Yes	Month to retrieve in YYYY-MM format (e.g., 2026-02).

Required role: org_admin or billing_viewer

Example request:

GET /v1/orgs/org_01J2K3L4M5/billing/usage/history?month=2026-02

Example response:

{
  "month": "2026-02",
  "daily_breakdown": [
    {
      "date": "2026-02-01",
      "api_calls": 1420,
      "dlp_scans": 680,
      "data_processed_bytes": 1073741824
    },
    {
      "date": "2026-02-02",
      "api_calls": 1835,
      "dlp_scans": 910,
      "data_processed_bytes": 1288490189
    }
  ],
  "totals": {
    "api_calls": 87412,
    "dlp_scans": 41230,
    "data_processed_bytes": 94489280512
  }
}

UsageHistoryResponse Schema

Field	Type	Description
month	string	The requested month in YYYY-MM format.
daily_breakdown	array	One entry per calendar day in the month.
daily_breakdown[].date	string (YYYY-MM-DD)	The calendar date for this row.
daily_breakdown[].api_calls	number	API calls counted on this date.
daily_breakdown[].dlp_scans	number	DLP scans executed on this date.
daily_breakdown[].data_processed_bytes	number	Total bytes processed on this date.
totals	object	Aggregate totals for the full requested month.
totals.api_calls	number	Total API calls for the month.
totals.dlp_scans	number	Total DLP scans for the month.
totals.data_processed_bytes	number	Total bytes processed for the month.

History Retention

Usage history is retained for 12 rolling months. Months older than 12 months are no longer accessible via the portal or API. If you require long-term usage records, export monthly CSVs before the 12-month retention window closes.

---

5. CSV Export Workflow

Exporting from the Portal

On the billing history page (/portal/billing/history), select the desired month using the month selector, then click the Export CSV button in the top-right corner of the daily breakdown table. The browser will download a .csv file named arbitex-usage-YYYY-MM.csv.

Required role: org_admin or billing_viewer

CSV Export API

The export endpoint returns the same daily breakdown data as the history API, formatted as a comma-separated values file:

GET /v1/orgs/{org_id}/billing/usage/history/export?month=YYYY-MM

Query parameters:

Parameter	Type	Required	Description
month	string	Yes	Month to export in YYYY-MM format.

Required role: org_admin or billing_viewer

Response headers:

Content-Type: text/csv
Content-Disposition: attachment; filename="arbitex-usage-2026-02.csv"

CSV format:

date,api_calls,dlp_scans,data_processed_bytes
2026-02-01,1420,680,1073741824
2026-02-02,1835,910,1288490189
2026-02-03,2104,1020,1503238554

Columns:

Column	Type	Description
date	YYYY-MM-DD	Calendar date for the row.
api_calls	integer	API calls counted on this date.
dlp_scans	integer	DLP scans executed on this date.
data_processed_bytes	integer	Total bytes processed on this date.

The CSV file does not include a totals row. Sum the columns in your analysis tool to produce monthly aggregates.

Note

CSV exports are audit-logged. Each export generates an audit event with the requesting user’s identity, the org ID, and the month exported. Audit events are visible in the audit log under the billing.usage.export event type.

Automating Monthly Exports

To automate monthly exports, use the API endpoint with a service account token that holds the billing_viewer role. An example shell script to export the previous calendar month:

#!/usr/bin/env bash
MONTH=$(date -d "last month" +%Y-%m)
ORG_ID="org_01J2K3L4M5"
TOKEN="your_api_token"

curl -s \
  -H "Authorization: Bearer ${TOKEN}" \
  -o "arbitex-usage-${MONTH}.csv" \
  "https://api.arbitex.ai/v1/orgs/${ORG_ID}/billing/usage/history/export?month=${MONTH}"

Schedule this script with cron or your CI/CD platform to build a local archive of monthly usage records.

---

6. Upgrade Path

Current Plan Display

The billing dashboard shows your current plan name and tier in the Plan Details card. The card includes:

• Plan name and tier (e.g., Team)
• Billing cycle (Monthly or Annual)
• Renewal or next invoice date
• A quick summary of current plan limits

Initiating an Upgrade

To upgrade your plan, click the Upgrade Plan button in the Plan Details card. This navigates to /portal/billing/upgrade.

The upgrade page presents:

1. Current plan summary — your active tier with current limits highlighted.
2. Available tiers — a side-by-side feature comparison table for all tiers above your current one.
3. Pricing summary — monthly or annual cost for each tier (contact sales pricing is shown for Enterprise).
4. Confirm upgrade button — once a target tier is selected, click to confirm.

Billing adjustment for upgrades is applied immediately at confirmation:

• Monthly billing: You are charged a prorated amount for the remainder of the current month, then billed at the new rate on the next billing cycle.
• Annual billing: You are charged the prorated difference between your current annual rate and the new annual rate, applied immediately.

Downgrading Your Plan

Downgrades are processed at the end of the current billing period, not immediately. To initiate a downgrade:

1. Navigate to /portal/billing/upgrade.
2. Select a lower tier.
3. Confirm the downgrade.

The portal displays a confirmation dialog showing the date on which the downgrade takes effect and which features will be reduced or removed.

Caution

Downgrading your plan may reduce your audit log retention period. For example, downgrading from SMB (180-day retention) to Team (90-day retention) means audit events older than 90 days will no longer be accessible after the downgrade takes effect. Export your audit log data before confirming a downgrade if you need to preserve historical audit records. See Audit Log Export for export instructions.

Enterprise Plan

The Enterprise tier requires custom pricing negotiated directly with the Arbitex sales team. When Enterprise is selected on the upgrade page, the Confirm Upgrade button is replaced with a Contact Sales call-to-action that opens a pre-filled inquiry form. A sales representative will follow up to discuss requirements, custom limits, SLA terms, and pricing.

Enterprise customers can also contact their assigned Technical Account Manager (TAM) directly to initiate a plan change or renegotiate terms at renewal.

Upgrade Impact on Active Sessions and Outposts

Plan upgrades take effect immediately. If your upgrade increases the outpost node limit (for example, from 1 node on Dev Pro to 3 nodes on Team), additional outpost registrations become available as soon as the upgrade is confirmed. There is no need to restart existing outpost instances or re-authenticate existing API sessions.

Tip

After upgrading, verify your new plan limits are reflected in the billing dashboard at /portal/billing. If the portal still shows old limits after 60 seconds, perform a hard refresh. If limits remain incorrect after five minutes, contact support with your org ID and upgrade confirmation reference.

---

Related Resources

• Cloud Portal Advanced Configuration — organization-level settings including timezone, MFA enforcement, IP allowlists, and data residency configuration.
• API Reference — Batch 34 — full endpoint reference for the billing usage, usage history, CSV export, and plan endpoints documented in this guide.
• Audit Log Export — instructions for exporting audit event data before performing plan downgrades.
• Portal Notifications — how billing overage alerts are surfaced through the portal notification system.