Skip to main content
Billing is usage-based and denominated in credits. A voice call is charged as a flat per-minute line; WhatsApp is charged per message. You read your balance and history from two customer endpoints; the internal cost model is not exposed.
A negative credit balance blocks new work. Credit enforcement is on by default: starting a new session, campaign dial, single call, inbound answer, or agent-test run while your balance is below zero is rejected with 402 insufficient_credits. A balance of exactly 0 is allowed — the call that takes you negative still runs — and a call already in progress is never interrupted: live calls and open conversations always finish. Overdraft allowances and per-workspace exemptions are set by your administrator.

​
How a voice call is priced

Every voice call — outbound phone, inbound phone, or web — is charged as a single flat line, voice_billing_minutes, priced per call type (outbound_phone, inbound_phone, web). This is the only line that carries credits for a call.
  • Pulse rounding. The billed duration is rounded up to the next whole pulse. The default pulse is 60 seconds (per-minute billing); your administrator can lower it — down to 1 second (per-second billing).
  • Free-below threshold. A call shorter than a minimum billable duration is free (billed at zero quantity). The default is 0 seconds, so every answered call is charged; your administrator can raise it.
The underlying components (session, telephony, model tokens, speech-to-text, text-to-speech, recording) still appear on your usage as line items with quantities, but their credit charge is 0 — the flat voice_billing_minutes line replaces them. The detail stays visible without double-charging.

​
What gets metered

A finalized voice call produces usage lines across these components. The flat voice_billing_minutes line carries the charge; every other line is recorded at zero credits (the Credited column). WhatsApp is billed differently. Token counts are reported by the model; minutes and characters are estimated from timestamps and transcript length. A phone call (inbound or outbound) meters the same duration on two telephony legs — a platform leg and a carrier leg — except when the call used your own SIP trunk (BYON), where the carrier leg is skipped. Realtime audio-to-audio models skip the separate speech-to-text / text-to-speech lines.

​
WhatsApp

WhatsApp is metered per message, not per session. Each outbound message emits one whatsapp_messages event, priced by conversation category — marketing, utility, authentication, or service. WhatsApp has no flat per-call line, so the zero-credit rule above doesn’t apply: both the whatsapp_messages events and the reply LLM’s llm_input_tokens / llm_output_tokens / llm_cached_tokens lines carry credits here. Metering is idempotent per message, so a retried send is never double-charged.

​
Credits & ledger

Your credit balance is the running sum of your ledger. Entries are signed: Charging is idempotent — a call’s usage is charged once. If usage is later corrected, the prior debit is reversed and re-charged, never added on top.

​
Read your usage

me/summary returns a summary object — customer_name, currency (INR), credits_granted, credits_used, credits_balance, total_tokens, total_minutes, and unpriced_usage_events — alongside a breakdown array carrying each component’s quantity and credits. The breakdown is where the flat voice_billing_minutes charge and the zero-credit detail lines appear. me/ledger returns your signed entries with a running balance_after.
These endpoints require a customer-admin bearer session and expose credits only — never internal cost. Rate cards and cross-customer accounts are administrator-only and aren’t part of the public API.