Billing & Usage Exports

note

API paths that contain tenant keep that word for compatibility. In the product it means your workspace.

The billing workspace exposes transparent usage data for each workspace so your finance or security team can reconcile consumption before invoices go out. Everything runs from the on-prem stack, no cloud metering or hidden SaaS dependencies. If a term is unfamiliar, open the Glossary.

Workspace billing

• UI route: #/tenant-billing
• Audience: workspace owners, workspace admins, and billing operators
• Purpose: view amount due, invoice status, payment history, and latest payment state without opening internal HUD screens

Billing data loads automatically when the page opens. The plan shows its customer name (Free Evaluation, Starter, Pro, or Enterprise), and a workspace without an invoice yet shows "No invoice yet" rather than a raw status code. Use Refresh to re-pull the latest state after a payment.

What you can do in workspace billing

1. See current plan + usage-backed estimate.
2. See latest invoice and amount_due_cents.
3. Track payment records (PENDING, VALIDATED, PROCESSING, PAID, FAILED).
4. Export evidence from related invoice/report flows as needed for audits.

The current billing route now opens on an overview screen, then breaks the rest of the workflow into explicit sections:

• Overview for workspace, plan, amount due, latest invoice, and latest payment state
• Invoices for invoice history
• Payments for payment history

This is a presentation change only; the underlying billing routes and status rules are the same.

Payment status meanings

• PENDING: payment record exists but has not been operator-validated yet.
• VALIDATED: Dralvia operator validated payment details; settlement may still be pending.
• PROCESSING: settlement is in flight.
• PAID: invoice is fully settled (amount_due_cents = 0).
• FAILED: settlement failed and requires operator follow-up.

If your team sees PENDING or FAILED for longer than expected, contact Dralvia billing operations with your workspace ID and invoice ID.

Stripe-backed payment status

Paid self-serve subscriptions already mirror Stripe webhook outcomes into the same Dralvia billing records used by #/tenant-billing.

• Stripe invoice.paid updates invoice/payment state to paid.
• Stripe invoice.payment_failed updates invoice/payment state to failed and moves the subscription into the backend grace-period path.
• Operator-assisted payment validation and mark-paid actions still use the same invoice/payment history shown on this page.

Current limitation

The workspace billing page does not yet show a dedicated subscription-level overdue/grace countdown card. Today, overdue/payment-failure state is reflected through the existing invoice/payment records and any operator follow-up, not through a separate subscription banner.

Workspace API endpoints

• GET /billing/tenant/summary
• GET /billing/tenant/invoices
• GET /billing/tenant/payments

These are workspace-scoped; the backend derives workspace context from your authenticated session/API key.

Dralvia-assisted payment operations

Dralvia billing operators use the same billing console for workspace payment operations:

• Validate payment records (POST /admin/billing/payments/validate)
• Mark invoices as paid (POST /admin/billing/payments/mark-paid)
• Review payment/audit history (GET /admin/billing/payments/history)
• Export payment-audit bundles (POST /admin/billing/payments/audit/export)

The internal billing workflow in the same console now separates those operator tasks into Operations, Audit, and Plans sections. When Dralvia marks an invoice as paid, #/tenant-billing updates immediately to show the new status.

What gets metered?

Metric	Description	Where you see it
Scans	URL and smart contract scans in the current window.	Usage & Limits (#/tenant-usage)
Repository scans	Repo ZIP reviews in the current window.	Usage & Limits
Shadow renders	Remote isolated page renders.	Usage & Limits
Reports and EvidencePacks	Generated evidence artifacts.	Evidence Reports and Usage & Limits

Each metric is aggregated per workspace and time window against your plan allowance. Dralvia operates the underlying metering; you always see the same numbers your invoice is based on.

Reviewing usage and exporting for finance

1. Open Usage & Limits (#/tenant-usage) to see the current window, consumption per metric, and remaining allowance (also available from GET /usage/summary).
2. Open Billing & Payments (#/tenant-billing) for the invoice and payment history behind each charge (also available from GET /billing/tenant/invoices and GET /billing/tenant/payments).
3. For a finance-grade export of invoices and usage over a custom window, ask Dralvia support with your workspace ID and the period; the export is produced from the same metering records.

Security & privacy

• All artifacts are stored on the same air-gapped volume as your EvidencePacks (Dralvia's exportable evidence reports).
• Billing export access is role-gated. If you need a downstream operator to pull exports, grant the appropriate workspace role or request exports from your Dralvia TAM.

Who this is for

This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day-to-day execution.

Role-based start here

• Workspace Owner: Start with Before you start, then complete Step-by-step and Known limits and rate limits.
• Workspace Admin: Focus on Step-by-step, What each button does, and API and automation.
• Security Analyst: Start at Day-2 operations and Troubleshooting, then use API error quick reference.
• Integrator/Engineer: Start at API and automation, then validate with Step-by-step and FAQ.

Before you start

Use this short checklist before making changes:

1. Confirm you are signed into the correct workspace account.
2. Confirm your role includes the permissions needed for this page.
3. Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
4. Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.

Step-by-step

Follow this sequence for predictable results:

1. Open the workspace from the workspace menu.
2. Review current status/health/last update indicators before making changes.
3. Apply one change at a time and save.
4. Run the available validate/probe/refresh action.
5. Confirm the expected output appears (status change, new event, successful result).
6. If behavior is not as expected, use Troubleshooting below before repeating actions.

Day-2 operations

After initial setup, keep this surface healthy with a simple routine:

1. Daily: verify data freshness and error banners.
2. Weekly: review trends, limits, and failed actions.
3. Monthly: review permissions, keys/tokens, and stale entities.
4. After any incident: capture evidence and update your internal operating notes.

What each button does

Button labels can vary by module, but behavior is consistent:

• Refresh: reloads the latest data from backend APIs without changing configuration.
• Save: persists workspace-scoped configuration changes.
• Run/Probe/Validate: executes a non-destructive health or verification action.
• Download: fetches workspace-scoped artifact(s) (for example bundle, checksum, signature, or report).
• Verify: checks integrity/consistency and returns pass/fail details.
• Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.

If a button appears disabled, check role permissions, required fields, and workspace license/feature entitlement first.

Self-check playbook

Use this 5-step isolation flow before escalating:

1. Configuration: confirm required inputs are present and formatted correctly.
2. Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
3. License/feature: confirm the feature is enabled for your workspace plan and module toggles.
4. Quota/rate limit: check for 429 responses and cooldown windows.
5. Service health: if you see 5xx, retry once after 30-60 seconds and capture exact error text.

If still failing, escalate with workspace ID, UTC timestamp, route, action, payload shape (no secrets), and screenshot/error response.

Troubleshooting

Use this quick triage order to reduce time-to-fix:

1. Auth/session: refresh token by signing out/in.
2. Workspace context: confirm you are in the correct workspace.
3. Inputs/config: verify required fields and formats.
4. Quota/license: confirm limits and feature entitlement.
5. Service health: retry after short delay if backend is transiently degraded.

For escalation, include workspace ID, timestamp (UTC), route name, action attempted, and full error message.

API and automation

Everything in this page should remain workspace-scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:

• Use authenticated requests bound to your workspace context.
• Use idempotency/retry controls where available.
• Validate outcomes in the UI after automated runs.

If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.

Next best actions

After finishing this page, continue with related workflows so your workspace setup stays end-to-end complete:

• EDR response and host actions
• Web Access Protection and dry-run events
• Identity risk and OAuth response
• EvidencePack verification and transparency log
• Risk economics and plan recommendation

FAQ

Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.

Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key/session is valid and mapped to the correct workspace scope.

Q: Can non-admin users use this page? A: Usually read-only access is possible; write actions require workspace-admin or equivalent roles.

Next steps

After finishing this guide:

1. Validate the result in the related dashboard/workspace.
2. Export or capture evidence if this affects compliance/incident operations.
3. Share the same runbook internally so other operators follow identical steps.
4. Return to Help Center for adjacent workflows.

API error quick reference

Use this matrix when a UI action fails with an HTTP/API error.

Error	Meaning	What to do now
401 Unauthorized	Session token is missing/expired or request is not authenticated.	Sign out/in, refresh once, then retry. Confirm your session is active in the correct workspace.
403 Forbidden	You are authenticated but your role is not allowed to perform this action.	Confirm your role includes the required permission for this button/action. Ask workspace admin to grant access.
404 Not Found	The route/resource does not exist in current workspace context (or feature not enabled).	Confirm URL/route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support.
429 Too Many Requests	Rate limit/quota window was exceeded.	Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server Error	Backend failed unexpectedly while processing the request.	Retry after 30-60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text.

Known limits and rate limits

These limits can vary by plan and feature, but behavior is consistent:

• Burst traffic can trigger 429 Too Many Requests.
• Workspace quotas apply per feature/module and reset on configured windows.
• Repeated retries without backoff can extend recovery time during saturation.

Recommended operator behavior:

1. Retry once after cooldown for 429 responses.
2. Use exponential backoff in automation.
3. Monitor usage/quota dashboards for sustained high utilization.
4. Request quota review when normal workload regularly approaches limits.