Debug entitlement and billing errors with Autumn data in a Sazabi thread

Last verified on Nov 8, 2026.

Usage-based billing adds a failure mode that ordinary logs explain badly: a customer is blocked from a feature, your app logs "not allowed", and the real reason is a balance, a plan attachment or a subscription state held in your billing layer. Autumn sits between your app and Stripe, so the answer is in Autumn. The Sazabi agent can read it next to the error that sent you looking.

What the Sazabi agent can do with Autumn

Sazabi connects to Autumn's hosted MCP server at mcp.useautumn.com/mcp. Authentication is an Autumn secret key (am_sk_...) from Developer > API Keys, which Sazabi stores and sends as a bearer token. Use a sandbox key to explore or a production key for live data. Per Sazabi's page, the agent can:

• Look up customers, their plans, features and balances.
• Read the pricing catalog: plans, features, credits and usage limits.
• Check and track feature usage and entitlements.
• Preview and manage subscriptions, schedules and billing changes.

Autumn's MCP page describes the server as billing, customer, plan, balance and log tools, plus four resources: autumn://docs/concepts, autumn://docs/plan-management, autumn://docs/billing and autumn://docs/logs. The last one is the investigator's resource. Autumn says it covers API request logs, Stripe webhook timelines, customer request histories and log analytics.

Writes go through a preview and approval flow, and Sazabi adds its per-connection read-only toggle. Preview a change, read it, and apply it yourself.

Questions it answers

• Why did check return allowed: false for this customer and feature?
• What plan is the customer on, and what balance remains for the feature?
• Did Autumn receive the Stripe webhook that should have changed the subscription?
• What requests did this customer's ID make to Autumn in the last hour?
• Does Autumn's record of the customer's plan match Stripe?

A worked example: a paying customer told they are out of credits

Support reports that a paying customer on example.com sees "usage limit reached". Your logs show your API returning 403 for user_4417 on the messages feature. You ask:

Our API returned 403 for customer user_4417 on feature "messages" at about
10:30 UTC. Look up that customer in Autumn: which plan are they on and what is
their messages balance? Then read the Autumn logs for their requests and the
Stripe webhook timeline around the last plan change.

The agent finds the 403s in your logs and shows the query. It then reads autumn://docs/concepts as Autumn instructs, looks the customer up, and reads their plan and balance. After that it reads the logs resource for the customer's request history and the Stripe webhook timeline.

Autumn's docs list what makes allowed true: an active plan with the feature, a balance above required_balance, or a usage-based feature that has not hit its spend limit. Compare those against what the agent found. A zero balance on an active plan points at usage tracking or a missing reset. No active plan, with a successful Stripe payment, points at a webhook that did not apply the change. A customer_not_found error in the request history means your app never created the customer before calling check, which is a code fix, not a billing one. Autumn's API reference also describes a read-only Verify call that compares Stripe subscriptions to Autumn's record, which is worth asking about when plan and payment disagree.

How it fits with other integrations

Autumn is a layer over Stripe, so the Stripe page covers the payments below it. Linear is where the fix goes, PostHog shows what the customer did before the block, and Slack hosts the thread. All connectors are listed under integrations, and plans are on pricing.