How do I connect my billing destination?
Connecting a billing destination tells CMD+K where to forward usage. We ship first-class adapters for Stripe Meter Events and Paddle Billing — plus a signed webhook for Lago or anything custom. The adapter layer is gateway-agnostic, so switching destinations never breaks your meter configuration.
Prerequisites
- An active Stripe account with at least one product and meter configured.
- A restricted Stripe secret key (
rk_live_…) with Meter events: write. - The meter ID you want CMD+K to push to (e.g.
mtr_abc123).
Setup
- Open Monetize → Billing destinations.
- Click Add destination and pick Stripe.
- Paste the restricted key and meter ID; click Test — we send a $0 dry-run event.
- Save. Forwarding starts on the next widget interaction.
Paddle
Paddle Billing has no live meter-event API, so the Paddle destination works on an accrue-then-charge cycle: CMD+K accumulates each customer's usage per calendar month (UTC) and, once the month closes, creates one one-time charge on the customer's Paddle subscription (effective_from: next_billing_period). The daily flush runs at 00:30 UTC; the destination row also has a Flush now button.
- In Paddle, create a per-unit price for usage (e.g. $0.01 per 1k tokens) and copy its
pri_…id. - Create a Paddle API key with subscription write access.
- Add destination → Paddle → pick sandbox/live, paste the key, map your meter to the price and set units-per-charge (e.g. 1000 tokens per unit, rounded up).
- Set the customer ID template so it resolves to each customer's
sub_…subscription id. - Click Test — for Paddle this verifies the API key without creating any charge.
- Scheduled cancellations — Paddle discards queued charges when a subscription is set to cancel at period end — use Flush now before cancelling a customer.
- Billing anchor — Charges land on the customer's next Paddle invoice, so a closed month can appear one invoice later than the usage month.
Event shape
The adapter forwards one event per billable widget turn:
json
{
"event_name": "cmdk_tokens",
"payload": {
"stripe_customer_id": "cus_xxx",
"value": "1280"
},
"identifier": "cmdk_evt_01HXXXX"
}- stripe_customer_id — looked up from your end-user's external_id mapping you provide via JWT or assistant config.
- value — unit you meter on — tokens, characters, or 1 per turn. Configurable per assistant.
- identifier — deterministic per turn; Stripe deduplicates retries automatically.
Next steps
FAQ
- Why restricted keys?
- Restricted keys with only 'Meter events: write' limit blast radius if the key ever leaks. CMD+K never needs read access or your full secret key.
- Can I forward to more than one destination?
- Yes — add multiple destinations and route different assistants to different meters from each assistant's Monetize tab.
- How is Paddle different from Stripe here?
- Paddle has no live meter-event API, so CMD+K accrues usage per customer per month and creates one one-time subscription charge when the month closes (daily flush at 00:30 UTC, or Flush now). Stripe receives each event in near-real-time instead.
- What does Paddle need from my end-user identity?
- The customer ID template must resolve to the customer's Paddle subscription id (sub_…) — or a ctm_… customer id with exactly one active subscription. Easiest: pass the sub_ id as the end-user sub in your widget JWT.
- What about Polar / Lago?
- Use the signed webhook destination — it delivers the same idempotent meter events to any endpoint you control. Native adapters follow demand.