You can now set Department and Class values on your NetSuite sync, alongside Location. Orb sends the values you choose at both the header and line level on every transaction type it syncs to NetSuite: sales orders, invoices, return authorizations and credit memos.

Many NetSuite accounts make these segments required on transaction forms for reporting. Previously, a transaction synced from Orb could fail to create in NetSuite when a required Department or Class was missing.

Learn more about configuring the NetSuite integration in our docs.

You can now create billable metrics as drafts through the API, edit them, and publish them when they're ready. Previously, draft metrics were only available in the dashboard.

• Create a draft by passing status: "draft" to POST /v1/metrics. Metrics are still created as active by default.
• Update a draft's sql and item_id with PUT /v1/metrics/{metric_id}. New SQL must use the same parameters as the existing SQL.
• Publish a draft with the new POST /v1/metrics/{metric_id}/publish endpoint. Published metrics can't return to draft.
• The billable_metric.edited webhook now includes status, item_id and sql in previous_attributes. Archive and unarchive events also include the previous status.

Note that a metric's SQL and parameter defaults can no longer be changed once a price uses the metric, in the dashboard or the API.

Learn more about billable metrics in our docs.

Settings in Orb has a brand new look, and it's packed with upgrades built to help you move faster.

• A visual refresh across every single page
• A smarter, reorganized layout, so everything lives exactly where you'd expect it to
• 🔎 Search, so you can jump straight to any setting in seconds, no more hunting
• 🏃‍♀️‍➡️ A brand new activity log, giving you full visibility into every change made

Learn more about account settings in our docs.

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.