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.

The credit ledger for each customer in the dashboard now opens with a Credit blocks view: a burndown chart of how the credit balance changes over the selected timeframe. Each lane is a credit block or recurring allocation, placed by effective date, under the total balance at the end of each day.

• See every active credit grant and recurring allocation in the timeframe, and how much of each block remains.
• Spot backdated and forward-dated blocks, expired unused credits, voids, scheduled blocks, and days with no credits left where usage is billed as overage.
• See who added each block.
• Hover the total balance to see what each block did that day, and select a block to filter the ledger below to its entries.

Learn more about prepaid credits in our docs.

The Users page in Settings > Users now makes it easier to find and review who has access to your Orb account, whether you're onboarding a teammate or running a quarterly access review.

• Export CSV: download your full user list in one click for access reviews and audits.
• Search: find a user by name or email.
• Page size: choose how many users to show per page. Previously, the page showed 20 users at a time.