Skip to main content
Settings in Flexprice control behavior for respective environment against tenant, providing complete isolation between different environments within and across tenants. All settings are scoped to per (tenant, environment) pair, validated on write, cached for one hour, and audited. Benefits:
  • Tenant and environment isolation β€” Each tenant and environment has its own settings; no cross-contamination
  • Flexible updates β€” Partial updates supported; only send the fields you want to change
  • Automatic caching β€” Settings are cached for one hour to reduce latency
  • Audit trail β€” All changes tracked with user and timestamp
  • Validated on write β€” Strict type checking and value constraints prevent invalid configuration

Available Settings

Flexprice supports the following setting keys:
  • Subscription Configuration (subscription_config) β€” Controls subscription auto-cancellation for unpaid invoices
  • Invoice Configuration (invoice_config) β€” Controls invoice number generation and due date calculation
  • Wallet Balance Alert Configuration (wallet_balance_alert_config) β€” Wallet balance alert thresholds configurations per tenant per environment
  • Bonus Credits Topup Configuration (bonus_credits_topup_config) β€” Slab-based bonus credit rules applied automatically to purchased wallet top-ups

Subscription Configuration

Key: subscription_config Controls subscription auto-cancellation for unpaid invoices. When enabled, subscriptions are automatically cancelled after grace period if invoices remain unpaid.

Schema

  • grace_period_days β€” Required for new settings; optional on update. Integer β‰₯ 1, no decimals. Number of days after invoice due date before auto-cancellation.
  • auto_cancellation_enabled β€” Optional; defaults to false. Boolean. Enable or disable auto-cancellation for this tenant and environment.

Default Values

When creating a new setting via API, defaults are:

What Happens When Auto-Cancellation Is Enabled

When you enable auto-cancellation and set a grace period:
  • Subscriptions with overdue unpaid invoices β€” If an invoice remains unpaid past its due date plus the grace period, the subscription is cancelled immediately (not at the end of the billing period).
  • You get notified β€” A subscription.canceled webhook is sent so you can sync your systems.
  • Clean shutdown β€” Future credit grants for that subscription are cancelled, and a final invoice is generated for any partial period used.
  • Audit trail β€” Cancellations are recorded with reason and metadata so you can see why and when a subscription was cancelled.

Validation

  • New settings: grace_period_days required, integer β‰₯ 1, no decimals. auto_cancellation_enabled optional, boolean, default false.
  • Updates: Partial updates allowed; only provided fields validated; omitted fields unchanged.

Invoice Configuration

Key: invoice_config Controls invoice number generation (prefix, format, sequence, timezone) and due date calculation.

Schema

  • prefix β€” Required for new settings; optional on update. Non-empty string, not only whitespace. Invoice number prefix (e.g. "INV").
  • format β€” Required for new settings; optional on update. One of YYYYMM, YYYYMMDD, YYMMDD, YY, YYYY. Date format in invoice number.
  • start_sequence β€” Required for new settings; optional on update. Integer β‰₯ 0, no decimals. Starting sequence number.
  • timezone β€” Required for new settings; optional on update. Valid IANA timezone (e.g. America/New_York, UTC) or common abbreviation (e.g. EST, GMT). Timezone for date formatting.
  • separator β€” Required for new settings; optional on update. String (empty allowed). Character(s) between prefix, date, and sequence (e.g. "-").
  • suffix_length β€” Required for new settings; optional on update. Integer 1–10. Number of digits for sequence (padded with zeros).
  • due_date_days β€” Optional; defaults to 1. Integer β‰₯ 0, no decimals. Number of days after invoice creation to set due date.

Default Values

When creating a new setting via API, defaults are:

What You Get

Invoice numbers are generated in the format you configure: prefix, optional separator, date (based on your format and timezone), then a zero-padded sequence. Each tenant and environment has its own sequence, so numbers stay unique and predictable. The sequence resets according to the date format (e.g. monthly for YYYYMM, daily for YYYYMMDD). Example with separator: Configuration: prefix: "INV", format: "YYYYMM", separator: "-", suffix_length: 5. Generated: INV-202501-00001, INV-202501-00002. Example without separator: Configuration: prefix: "INV", format: "YYYYMM", separator: "", suffix_length: 5. Generated: INV20250100001, INV20250100002.

Supported Timezones

  • IANA names (recommended): America/New_York, Europe/London, Asia/Tokyo, UTC.
  • Common abbreviations: EST, CST, MST, PST, GMT, CET, EET, IST, JST, KST, AEST, AWST, and more.

Validation

  • New settings: All fields except due_date_days required; see constraints above.
  • Updates: Partial updates allowed; same rules for provided fields; omitted fields unchanged.

Wallet Balance Alert Configuration

Key: wallet_balance_alert_config Sets the default balance alert configuration for the tenant and environment. It applies only to wallets that do not have their own alert settings. Per-wallet alert configuration is done via Wallet Sentinel Alerts (or alert_settings on the wallet in the API).

What This Setting Controls

  • When enabled β€” Wallets in this tenant and environment that have no per-wallet alert settings use this config as their default. Balance alerts run for those wallets using the thresholds you set here.
  • When disabled β€” Wallets that would otherwise use this default do not receive balance alerts until they have their own alert settings or you turn this setting back on.
  • Per-wallet overrides β€” Any wallet with its own alert_settings always uses those; this setting only applies to wallets without per-wallet config.
Resolution order for a given wallet: Flexprice uses the wallet’s own alert settings if present; otherwise it uses this tenant-and-environment default. If the default is disabled, wallets without per-wallet settings do not receive balance alerts.

Schema

  • alert_enabled β€” Required. Boolean. Turn alerts on or off at tenant and environment level.
  • critical, warning, info β€” Optional. Each has threshold (string, e.g. "0", "-5", "10") and condition ("below" or "above").

Default Value

When no custom value is stored (or after DELETE), the default is:

Validation

  • If alert_enabled is true, at least one of critical, warning, or info must be present.
  • Threshold ordering: for "below", critical < warning < info; for "above", critical > warning > info (as applicable).

Alert behavior (same as per-wallet alerts)

Once a wallet is using alert config (either its own or this default), behavior matches Wallet Sentinel Alerts: balance is monitored against the thresholds, Info / Warning / Critical are raised when thresholds are crossed, state is updated on the wallet, and webhooks are sent when alert state changes.

Bonus Credits Topup Configuration

Key: bonus_credits_topup_config Defines slab-based rules for granting bonus credits automatically on purchased wallet top-ups. When enabled, a top-up’s credit amount is matched against a table of thresholds, and the matching slab’s bonus is granted alongside the purchase.

Schema

  • enabled β€” Required. Boolean. Turn automatic slab-based bonus resolution on or off for this tenant and environment.
  • slabs β€” Required and non-empty if enabled is true; optional otherwise. Array of slab objects, evaluated in list order, so they must be sorted descending by threshold. The first slab a top-up’s credit amount clears is the one that applies.
    • threshold β€” Required. Decimal string β‰₯ 0. The credit amount being purchased is compared against this value.
    • operator β€” Required. Only gte is accepted; the top-up’s credit amount must be greater than or equal to threshold to match.
    • bonus.type β€” Required. flat or percentage.
    • bonus.value β€” Required. Decimal string β‰₯ 0. For flat, this is the bonus credit amount added as-is. For percentage, this is a percentage of the credits being purchased.
    • expiration_duration / expiration_duration_unit β€” Optional; must be set together or not at all. Sets an expiry for bonus credits granted from this slab, unless the top-up request already sets bonus_credits_expiry_date_utc explicitly. Unit is one of DAY, WEEK, MONTH, YEAR.

Default Values

When creating a new setting via API, defaults are:

What Happens When Enabled

  • Applies only to purchased credits β€” Slab resolution runs only for top-ups with transaction_reason set to PURCHASED_CREDIT_DIRECT or PURCHASED_CREDIT_INVOICED (including pay-first checkout). Free credit top-ups never receive a bonus.
  • Manual override skips resolution β€” If the top-up request sets bonus_credits_to_add directly, slab resolution does not run for that top-up.
  • Bonus is a separate transaction β€” The bonus is recorded as its own wallet transaction with transaction_reason: PURCHASED_CREDIT_BONUS, linked to the purchase transaction via parent_transaction_id. It shares the purchase transaction’s status and completes with it.
See Top-Up Wallet for how slabs resolve against a purchase, the manual override, and how the bonus transaction is recorded. See the Top-Up Wallet API Reference for the bonus_credits_to_add and bonus_credits_expiry_date_utc request fields.

Validation

  • New settings: enabled required, boolean. If enabled is true, slabs required, non-empty.
  • Slab constraints: operator must be gte; threshold β‰₯ 0; bonus.type one of flat, percentage; bonus.value β‰₯ 0; expiration_duration and expiration_duration_unit must both be set or both omitted; slabs must be sorted strictly descending by threshold.
  • Updates: Partial updates allowed; only provided fields validated; omitted fields unchanged.

API Endpoints

Get Setting

Parameters:
  • key (path): Required. One of: subscription_config, invoice_config
Response:
Error Responses:
  • 404 Not Found: Setting not found for tenant Γ— environment
  • 400 Bad Request: Invalid setting key
  • 403 Forbidden: Missing tenant or environment context

Create/Update Setting

Parameters:
  • key (path): Required. One of: subscription_config, invoice_config
Request:
Response:
Error Responses:
  • 400 Bad Request: Invalid setting key or validation failed
  • 403 Forbidden: Missing tenant or environment context
Behavior:
  • Single endpoint handles both creation and updates
  • If setting doesn’t exist for tenant Γ— environment:
    • Creates new setting
    • All required fields must be provided
    • Default values applied for optional fields
  • If setting exists for tenant Γ— environment:
    • Updates existing setting
    • Supports partial updates
    • Only provided fields are validated
    • Omitted fields retain their existing values
    • No defaults are applied

Delete Setting

Parameters:
  • key (path): Required. One of: subscription_config, invoice_config
Response:
Error Responses:
  • 404 Not Found: Setting not found for tenant Γ— environment
  • 400 Bad Request: Invalid setting key
  • 403 Forbidden: Missing tenant or environment context

Use Cases

Subscription Auto-Cancellation

  • SaaS with trial plans β€” Auto-cancel free trials after grace period if no payment method is added
  • B2B billing β€” Cancel subscriptions with overdue invoices after a grace period (e.g. 30 days)
  • Compliance β€” Automatically stop service for customers who haven’t paid within the grace period

Invoice Numbering

  • Multi-region operations β€” Use timezone to generate invoice numbers in the customer’s local time
  • Custom branding β€” Set prefix and separator to match your invoice format (e.g. ACME-202501-00001)
  • Sequence isolation β€” Each tenant and environment has its own sequence; no conflicts

Wallet Balance Alerts (Tenant and Environment Default)

  • Enable alerts for all wallets β€” Set tenant and environment default so new wallets inherit alert config
  • Disable alerts globally β€” Turn off async consumer for that environment by setting alert_enabled: false
  • Fallback for wallets without config β€” Wallets with no alert_settings use this default

Bonus Credits on Top-Up

  • Volume incentives β€” Grant a larger bonus on bigger top-ups (e.g. 10% bonus at $200+) to encourage customers to purchase more credits at once
  • Flat promotional bonus β€” Grant a fixed bonus amount for top-ups that clear a lower threshold (e.g. 50 bonus credits at $100+)
  • Automatic, no per-request work β€” Configure the slab table once; the bonus is resolved on every purchased-credit top-up without callers passing bonus fields

Best Practices

πŸ’‘ Send required fields on create β€” When creating a new setting, include all required fields; defaults apply only on API create. πŸ’‘ Use partial updates β€” Send only the fields you want to change; omitted fields keep their existing values. πŸ’‘ Prefer IANA timezones β€” For invoice_config, use IANA names (e.g. America/New_York) instead of abbreviations for clarity and daylight saving time support. πŸ’‘ Set a default for wallet balance alerts β€” Use wallet_balance_alert_config to define default thresholds for all wallets in this tenant and environment that don’t have their own alert settings. Enable it so those wallets get balance alerts; disable or DELETE to turn alerts off for them. πŸ’‘ Restrict who can change settings β€” Limit setting changes to admin users; use tenant-scoped API keys and review audit logs. πŸ’‘ Match grace period to your dunning process β€” Set grace_period_days to align with how long you allow overdue invoices before cancelling (e.g. after how many reminder emails or days). πŸ’‘ Monitor auto-cancellation outcomes β€” Use subscription.canceled webhooks to see which subscriptions were cancelled and adjust grace period or dunning if needed. πŸ’‘ Use invoice prefix and format for traceability β€” A clear prefix and consistent date format in invoice numbers make it easier to match invoices to periods and environments. πŸ’‘ Combine with per-wallet alerts β€” Set wallet_balance_alert_config as the default, then override on specific wallets via Wallet Sentinel Alerts where you need different thresholds. πŸ’‘ Sort slabs descending, and use round thresholds β€” Since the first matching slab wins, keep slabs sorted from highest to lowest threshold and pick thresholds that make the applicable bracket predictable at a glance.