Orb now sends webhooks from a dedicated set of IP addresses, so you can allowlist exactly where Orb traffic comes from.

If your infrastructure uses a strict firewall for inbound traffic, you can now receive Orb webhooks without loosening those rules. Add Orb's source IP addresses to the allowlist for your webhook endpoints and keep your existing security posture intact.

• Allowlist Orb's source IP addresses on the firewall in front of your webhook endpoints.
• The current list of addresses is maintained in the webhook security guide.

Learn more about webhook source IP addresses in our docs.

The default event volume limit in live mode is now 200,000 events per minute, about 300 million events per day, with no setup required. Previously, the default was 10,000 events per minute. If you need more, contact Orb support.

The limit counts events, not requests, so batching is how you use your full volume. Each call to the ingest endpoint (POST /v1/ingest) accepts up to 500 events. Ingestion also has a request rate safeguard, so integrations that send one event per request may hit it before the volume limit.

• Test mode stays at 2,000 events per minute, and trial accounts at 100 events per minute.
• Above about 10,000 events per second, we recommend syncing events through an S3 or GCS bucket for resiliency.

Learn more about rate limits in our docs.

You can now list subscriptions with GET /subscriptions/summary, a lighter version of the subscriptions list endpoint: each subscription comes back with its own fields, and its plan and customer are returned as references rather than full objects.

To keep responses fast, the summary leaves out derived fields such as:

• Price intervals
• Billing periods
• Plan phases

Use it when you need to page through subscriptions quickly and only need their core fields, and fetch an individual subscription when you need its pricing or billing period details.

Learn more about summary lists in our docs.

Prices can now live in a central product catalog and be shared across plans. Previously, a price could only be scoped to a single plan, so a price used across several tiers had to be copied into each plan separately. Now you define a list price once and reference it from every plan that uses it, so you can see which products you sell, at what prices, and which of your customers are on rates that differ from your standard pricing.

• Define once, reference everywhere: list prices live in the product catalog and can be referenced by multiple plans.
• Dimensional prices: dimensional prices can be defined once and shared across plans, alongside other common price types.
• Full API support: every price management and sharing operation in the dashboard is also available through the API.
• Activity feed: every pricing and packaging change records who made it, when, and why.

Shared products and prices are the default for new Orb accounts, which now set up catalog-first: ingest events, create metrics, build your product catalog, package prices into plans, then create subscriptions. Negotiated rates layer on top of list prices as overrides.

Learn more about the product catalog in our docs.

You can now set per-group overrides on multidimensional spend alerts without specifying a value for every grouping key. Any key you leave out of an override matches any value, so a single override can cover a whole slice of your customers' usage.

Previously, each override needed a value for every grouping key, so an alert grouped by several event properties required a separate override for each combination. Now you can, for example, raise the threshold for every group where region is eu, whatever the other keys are.

• Set a custom threshold or mute alerts for groups that match only the keys you choose
• Configure overrides under per-group overrides when creating or editing a spend alert in the dashboard

Learn more about spend alerts in our docs. Reach out to your Orb contact to request access for grouped spend alerts.

You can now archive and unarchive billable metrics through the Orb API, matching what's already possible in the dashboard. Archive metrics you no longer bill on to keep your catalog tidy without deleting them, and unarchive them if you need them again.

• Archive a metric with POST /metrics/{metric_id}/archive.
• Unarchive it with POST /metrics/{metric_id}/unarchive.
• Filter GET /metrics with the status parameter to list only active or only archived metrics.

Learn more about billable metrics in our docs.

You can now fetch a summary of a customer's credit balance with a single request to GET /v1/customers/{customer_id}/credits/balance. Previously, getting a total balance meant paging through a customer's credit blocks and adding them up yourself.

The response includes:

• balance: the customer's current credit balance
• pending_payment_balance: credits that are pending payment
• next_expiry_date and next_expiry_balance: when the next credits expire, and how many
• currency: the currency of the balance

Learn more about credits in our docs.

New webhook endpoints now use standard payloads by default. Standard payloads include each object's own fields and references to related objects, but leave out invoice line items and subscription price intervals, so they're smaller and faster to build and deliver. When you need the full object, fetch it from the API after the webhook arrives.

• Choose a payload style, Standard or Expanded, when you create an endpoint in Developers > Webhooks.
• Switch an existing expanded endpoint to standard payloads at any time.
• Every webhook now has typed, autogenerated reference docs for both payload styles.

Note that existing endpoints keep receiving expanded payloads until you change them.

Learn more about webhooks in our docs.

You can now update the metadata on an existing credit block with the new PUT /v1/credit_blocks/{block_id} endpoint.

Use it to keep the identifiers and tags you store on credit blocks in sync with your own systems after a block has been issued, for example to record a contract reference, the reason for a grant, or a reconciliation status.

Send the keys you want to set, or set a key to null to remove it.

Orb MCP (Model Context Protocol) is not available in Early Access, so your AI agents can connect directly to your Orb account and work with your billing data.

Learn more about setting up the MCP server in our docs.