Advanced Features
Usage Metering By Stripe
Stripe metering lets you monetize and control your chatbot's usage with your own Stripe account. It is especially useful when you resell a chatbot to your customers or run it as a service on top of your specialized knowledge base. This feature is available on the Standard Plan or above, and only chatbot admins can change metering settings.
You can use it for three purposes, selectable per chatbot:
- Usage caps only — enforce daily/weekly/monthly limits per customer or chatbot-wide, with no billing.
- Usage-based billing only — send usage events to a Stripe meter and invoice your customers automatically.
- Both — bill for usage and enforce caps at the same time.
You stay in control of subscriptions
Chat Data pushes usage meter events and creates the Product and Price on your Stripe account, but it never creates subscriptions on your customers' behalf. Your customers subscribe through your own flow — a Stripe Checkout link Chat Data can generate for them, your own Payment Link, or your onboarding — so there is never a surprise charge Chat Data initiated.
Setup
1. Connect Stripe
Connect your Stripe account to the chatbot from Settings > Metering (or the Stripe integration panel). The recommended method is the Stripe Connect flow — an OAuth authorization scoped to the chatbot that you can revoke from Stripe at any time.
An account-level Stripe API key (added on your account page) also works and remains supported for existing setups.
Switching Stripe accounts
If you later connect a different Stripe account, the Products, Prices, and customers created under the old account are not migrated — they stay on the old account, and Chat Data re-creates what it needs on the new one the next time you save the metering settings. Customers subscribed under the old account remain the old account's billing relationship.
2. Pick a Stripe meter and unit
Create a meter in your Stripe dashboard under Billing → Meters (see Stripe's usage-based billing guide), then select it in the chatbot's Metering settings. Use Sync from Stripe to refresh the meter list after creating one.
Choose the unit Chat Data sends:
- Message credits — each reply reports its consumed Chat Data credits (weighted by model, audio, and other factors). Zero-credit replies (for example, cached responses) are not billed.
- Messages — every delivered reply reports exactly 1 unit, regardless of its credit cost. Internal workflow steps that don't produce a visible reply (API calls, routing, and similar) are never billed as messages.
3. Identify the customer
- Static customer — all usage is billed to one fixed customer: the customer you resold the chatbot to. You can identify them by Stripe customer ID (
cus_..., the most direct option — Chat Data verifies it exists when you save) or by an email/name/phone that Chat Data resolves to a Stripe customer on your account. - Dynamic (per-lead) customer — each visitor is billed individually, resolved from the lead form field you choose (email is the most reliable identifier; name and phone also work). The lead form — and the specific field — must be enabled on the chatbot, otherwise the save is rejected.
For dynamic customers, choose what happens when a visitor has no lead information yet:
- Create — chat proceeds; a Stripe customer is created once the lead identifies themselves. Messages before identification are not metered.
- Block — the visitor must identify themselves before chatting; they see your configurable identification-required message.
- Anonymous fallback — unidentified usage rolls up to one shared per-chatbot "anonymous" Stripe customer, so no usage goes unmetered.
Usage caps
When your purpose includes caps, configure:
- Scope — Per customer (each user gets their own allowance) or Global (one shared allowance for the whole chatbot).
- Reset period — daily, weekly, monthly, lifetime (never resets), or the Stripe customer's billing cycle. The billing-cycle option follows each customer's actual subscription period; customers without a subscription fall back to a monthly window anchored on when they were first seen.
- Limit — the allowance in your chosen unit (credits or messages).
When the cap is hit, pick one of:
- Block — the bot refuses to reply with your custom message. You can use
{{cap}},{{usage}}, and{{reset_at}}placeholders in it. The check runs before the AI is invoked, so a blocked message never spends your credits. - Allow & charge overage — the conversation continues and, when billing is active, the overage usage keeps being metered at your configured price. In cap-only mode this acts as a soft cap: usage continues, nothing is charged, and the warning notifications below still fire.
Cap accuracy
The cap contract is "blocked when usage at the start of a message is at or over the cap." With message metering this is exact. With credit metering, a customer just under the cap can complete one more reply whose cost isn't known until the AI finishes — a bounded overshoot of at most one message.
You can also set a soft warning threshold (a percentage of the cap) that triggers the notification emails described below before the customer is cut off.
Pricing (billing purposes)
Chat Data creates and manages the metered Product and Price on your Stripe account from the pricing you configure — you don't have to build them in the Stripe dashboard.
- Per unit — a flat price per credit or message.
- Package — a bundle price, e.g. $15 per 1,000 credits (partial bundles round up).
- Volume-tiered — the unit price falls as usage grows; the final tier is unbounded.
You also choose the currency, the invoice cadence (monthly, weekly, your customers' Stripe subscription cycle, or manual/on-demand invoicing), and the tax behavior (exclusive, inclusive, or let Stripe Tax decide).
Price changes create a new Price version
Editing pricing (or re-activating billing, or changing the meter) creates a new Stripe Price. Customers already subscribed keep their current price — Stripe does not migrate active subscriptions, and Chat Data won't either. New subscriptions get the new price. To move existing customers, migrate them in your Stripe dashboard.
Changing the meter is guarded
A metered Price is permanently bound to its meter. If you change the chatbot's meter while customers hold active subscriptions on any Price this chatbot created, the save is rejected with a list of the affected subscriptions — otherwise those customers would keep paying a subscription that no longer bills anything. Migrate or cancel those subscriptions first.
Unsubscribed customers (block and invite)
With billing on, you decide what happens when the customer has no active subscription on your meter:
- Allow & meter (default) — they chat normally and their usage is metered; Stripe bills them once they subscribe.
- Block & invite to subscribe — they are stopped with your message and a subscribe link, at the moment you choose:
- Immediately — before their first reply.
- After N free messages — they get N free messages per period first (N must be a whole number; one message is counted per customer message, even if a workflow sends several replies).
- At the cap — they chat until they hit the usage cap, then see the subscribe prompt instead of the plain cap-block message.
The subscribe link can be a Stripe Checkout session Chat Data generates against your Price (Checkout creates an auto-renewing monthly subscription, so it isn't compatible with the manual or subscription-cycle cadences — use a custom link for those) or your own URL with placeholders such as {{subscribe_link}}, resolved from the lead and chat context.
Block & invite in static-customer mode
This also works with a static customer — useful for a self-serve re-subscription path when the customer you resold the bot to churns. But remember that in static mode every visitor maps to that one customer: if it has no active subscription, the subscribe prompt is shown to everyone who chats with the bot, not just your billing contact. Use it only when the person chatting is the one who pays (internal or single-seat bots). For a bot resold to an organization whose end-users chat, keep Allow & meter and follow up on churn out-of-band.
On the website widget the invitation renders as a subscribe card with a call-to-action button — in normal chat, streamed replies, and realtime voice sessions (the voice session ends gracefully and the card appears in the chat transcript). On channels that can't render cards (WhatsApp, Messenger, and other third-party integrations), the same message is delivered as plain text with the link included.
Notifications
- Usage thresholds — when a customer (or the global counter) crosses your warning threshold or hits the cap, Chat Data emails your workspace owners (or a recipient list you configure, up to 5 addresses; each recipient consumes one workspace email credit) and, optionally, the customer themselves. Each threshold notifies once per reset period; if a notification can't be sent (for example, no email credits), it automatically retries once the issue clears.
- Custom email template — you can override the From name, subject, and body of these emails, with
{{customer_name}},{{usage}},{{cap}},{{threshold}},{{reset_at}}, and{{chatbot_name}}placeholders. - Billing-pipeline alerts — if Stripe starts rejecting usage events (for example, the meter was deleted or the connection was revoked) or subscribe-link generation fails, workspace owners get an alert email (at most one per day) so unbilled usage never fails silently.
Chat availability comes first
Metering is designed to never take your chatbot down: transient Stripe or infrastructure errors fail open (the conversation continues), and usage that could not be billed is not counted against caps. Meter events and notifications are delivered off the reply path, so your customers never wait on Stripe.
Verify the metering
After saving, chat with the chatbot and open the meter's page in your Stripe dashboard — you'll see the usage events arrive:
If you configured billing, the Metering settings page also shows the synced Product and Price after a successful save.
Legacy setup (account-level API key)
Earlier versions of this feature used an account-level Stripe API key and required you to create the Product and pricing in the Stripe dashboard yourself. That configuration keeps working — existing chatbots behave exactly as before until you explicitly opt into the new caps or billing options in the Metering settings. The video below demonstrates the legacy key-based setup:
Frequently Asked Questions
What do I need to set up before enabling metering on a chatbot?
First add your Stripe API key in your Chat Data account page, then create a usage meter and pricing model in Stripe before selecting that meter in the chatbot Settings > Metering tab.
What is the difference between static and dynamic customer metering?
Static customer metering always charges a fixed customer you provide, while dynamic customer metering uses collected lead information such as name, email, or phone to decide who should be charged. If that identifier is missing, the message is not metered.
How do I verify that Stripe metering is working after setup?
After saving the metering settings, chat with the chatbot and then check the corresponding Stripe meter page to confirm that usage events are being emitted.