From Notification to Activation: How Orb Thinks About Webhooks

Modern billing isn't static. Subscriptions get created, upgraded, and cancelled. Usage accumulates, payments fail, thresholds get crossed, and credits deplete. For any company running on usage-based pricing, these events are happening continuously across their entire customer base and every one of them has consequences that the rest of their systems need to act on.

Webhooks are what make this possible: the mechanism that lets the billing state escape the billing layer and activate everything that depends on it. When a plan changes, entitlements enforce themselves. When a payment fails, a dunning workflow starts. When a customer hits a ceiling, your GTM team knows immediately.

Orb is built around making all of that work reliably, in real time, at scale.

The infrastructure behind operational billing

Orb is built to make billing a real-time strategy function, not something teams reconcile at the end of the month. That requires every billing event to reach the systems that depend on it instantly.

Webhooks aren't a notification layer; they're the activation layer that connects billing state to the rest of the business.

That distinction shapes everything about how Orb's webhook system is built. Every meaningful billing event has a corresponding webhook across six categories: resource lifecycle changes, usage and spend alerts, balance events, dunning, accounting sync, and data exports. The coverage is broad by design, because any gap in what's observable is a gap in your ability to respond.

Reliability is non-negotiable, and Orb's webhook system is built to reflect that through:

• At-least-once delivery: Every event is guaranteed to reach its destination, even if the receiving endpoint is temporarily unavailable
• Automatic retries: A defined retry schedule ensures nothing gets dropped if delivery fails on the first attempt
• Configurable endpoints: Route different event types to different destinations, so the right systems get only the signals they need
• SDK helpers in Python, Node, and Go: Built-in signature verification and idempotency keys so teams can build on top of Orb's webhooks with confidence

Less payload, more signal

There's a practical problem with full webhook payloads at scale: they can get enormous. An invoice with hundreds or thousands of line items produces a payload that's expensive to deliver and expensive to parse. For high-volume customers, that means slower processing, a higher risk of delivery timeouts, and handler code doing a lot of work it doesn't need to do.

Orb's slim webhooks feature addresses this directly. When enabled, invoice payloads send everything except line items, the primary source of payload bloat. Subscription payloads are trimmed to the essentials: just enough to know what changed and act on it.

The recommended integration pattern is straightforward:

• Receive the webhook event
• Read the event type and resource ID from the payload
• Fetch the full resource via API if detailed data is needed
• Process accordingly

This pattern isn't just more efficient, it's actually safer. A fully embedded payload represents the state of the resource at the moment the event was emitted, not necessarily when your handler processes it. Fetching current state via API eliminates that risk entirely. It's becoming the standard pattern across the industry, and for good reason.

Billing that the business runs on

Better webhooks are a feature. But what they represent is a bigger shift: billing that the whole business can act on, in real time. When the signal is reliable, comprehensive, and fast enough to build on, billing stops being a system teams work around and starts being one they run on. That's the idea behind revenue design, and webhooks are a core part of what makes it real.

Explore the full webhook documentation here, or get in touch to learn more. For a full look at what shipped, check out our changelog.