Orb now automatically generates receipt PDFs when an invoice is paid. This includes payments made via auto-collection, through the invoice or customer portal, or when an issued invoice reflects a $0 balance.

Receipt PDFs are:

• Included as attachments in the payment success email.
• Downloadable from the invoice portal, customer portal, and the invoice page in the Orb dashboard.
• Accessible via the API on the invoice resource, with a download link available for each successful payment attempt.

Simulations let you understand the impact of any price evolution before you launch. Now, the full feature richness of Orb's billing engine is fully supported in Simulations — try it now.

What's new:

1. ✅ Start from an existing plan, and easily simulate changes to optimize revenue capture (changing tier boundaries, updating rates, and more).
2. ✅ Experiment with packaging or build out new pricing completely from scratch.
3. ✅ Simulate minimums, discounts, maximums... you name it.
4. ✅ Allocations + credits — tune your included allocation and top-ups to actual customer usage and needs.
5. ✅ Dimensional price groups? Let's set it up.

Build scenarios for different pricing strategies and run them against historical usage data in Orb. Simulations allow you to visualize price changes before you make them, without any of the complicated data legwork or churn risk of live testing with customers. Learn more in our docs.

We've launched a new API endpoint that enables you to evaluate the output of multiple prices for a given customer and time range. This powerful endpoint supports up to 100 prices in a single request, helping you build more detailed usage dashboards and audit invoice calculations.

Key capabilities:

• Evaluate up to 100 prices in a single API call for improved performance
• Use ingested or preview events - evaluate against real usage data or test with up to 500 preview events
• Advanced filtering and grouping with computed properties for granular analysis
• Inline price definitions - test new pricing models without creating them first

Common use cases:

• Build detailed usage breakdowns for customer dashboards
• Audit and verify invoice line item subtotals
• Test pricing changes before implementation
• Display usage patterns grouped by custom dimensions (e.g., by hour, region, or product feature)

Example grouping: Group usage by hour and custom property: ["hour_floor_timestamp_millis(timestamp_millis)", "region"]

Example filtering: Filter for specific usage: product_type = 'premium' AND region = 'us-east'

The endpoint is available now at POST /prices/evaluate. Check out our Querying data with SQL page for additional details and examples.

Over the past few months, many customers have launched GenAI features and wrestle with the same question: "How do we monetize this?" This inspired us to build something to help our customers iterate and refine their pricing strategy.

Orb Simulations lets you build scenarios for different pricing strategies and run them against historical usage data in Orb. You can visualize price changes before you make them, without any of the complicated data legwork or churn risk of live testing with customers.

Use cases:

1. Identify optimal price points to reduce churn or customer impact
2. Experiment with different value metrics (tokens? requests? outcomes?)
3. Model revenue impact across different pricing models

Try Simulations now in Beta, or learn more in our docs. When made generally available, we’ll update you on pricing. For new customers, join the waitlist.

Orb now has support for creating hierarchical relationships between your customers to power flexible pricing, usage aggregation, and invoicing.

This capability is particularly valuable when your customers desire to aggregate usage across multiple customers on a single parent invoice while maintaining the ability to configure pricing per customer or groups of customers.

Learn more about this new powerful capability in our product documentation

Orb's API now supports adding, removing, and replacing prices when creating a new subscription, or changing the plan for an existing subscription (See: Subscription Price Overrides). This is useful when a new customer has negotiated one or more different prices for a specific plan than the plan's default prices.

For information on how to use this feature, see the API specification:

• Create subscription API
• Schedule plan change API

Orb now supports specifying a custom billing cadence or one-time service period. Previously, prices could only recur monthly, quarterly, semi-annually, or annually. Now you're able to specify a custom duration in days or months. You can also now specify a custom service period duration for one-time prices, which determines the duration of the line item.

Orb's API now supports the dry running of requests. Dry running API requests allows you to validate the correctness of a request without making any actual changes to the system. This feature is particularly useful for ensuring that the request does not contain any errors and for previewing the potential response of a mutation before committing it.

Dry-running a request is as simple as including a “Dry-Run” header with a value of “True”, as shown below:

curl --request POST \
     --url https://api.withorb.com/v1/subscriptions \
      --header 'Dry-Run: True' \
     --header 'Accept: application/json' \
     --header 'Authorization: Bearer null' \
     --header 'Content-Type: application/json'

More information can be found in our documentation.

Orb now allows adding and removing prices during subscription creation and plan change. Previously, plan overrides only allowed prices to be modified. This allows the creation of a wide variety of custom plans using a small number of template plans, without having to construct the new plans from scratch. It also makes it easy to create add-ons to existing plans and subscriptions.

See the docs here: Subscription price overrides

Orb's backfill feature allows you to amend or replace events in a given time frame. This can be useful in cases where revising events is necessary, such as in the case of incorrect event reporting.

Backfills now support filtering across time ranges and with computed properties, which enables the expressiveness of SQL when replacing events. Using the `deprecation_filter` field requires `replace_existing_events` to be true and the filter must be an expression that is coercible to a boolean - for more information, see the docs here.