> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reply.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Get billing details
>
**Coming soon.** This endpoint will be available by early October 2026.
_Requires the `billing:read` scope (or a broader one that includes it)._
See the plan you are on and how many active contacts the current billing month has consumed, day by day. A
contact counts once per pool per month, on the day it is first touched. The `activeContacts` section follows
`billingScope`: under `organization` it holds one pool shared by every team, with each day split across the
teams you belong to; under `team` it holds one entry per team you can see, each with its own subscription
and pool. Available to the organization owner, who sees every team, and to users with the Plans and Billing
permission, who see the teams they belong to.
## OpenAPI
````yaml /api-reference/bundled.yaml get /v3/billing
openapi: 3.1.0
info:
version: 3.0.0
title: Reply API
description: API for managing email sequences, contacts, and automation workflows
servers:
- url: https://api.reply.io
security:
- bearerAuth: []
tags:
- name: Contacts
description: Manage individual contacts
- name: Contact Lists
description: Manage contact lists and contact membership
- name: Accounts
description: Manage accounts (companies/organizations)
- name: Account Lists
description: Manage account lists and account membership
- name: Custom Fields
description: Manage custom contact fields
- name: Prompt Actions
description: Save reusable AI prompts and run them on contacts to fill custom fields
- name: Contact Blacklist Rules
description: Manage blacklist rules for domains, emails, and email exceptions
- name: Live Data
description: >-
Find new contacts via Live Data searches and read typeahead values for the
Live Data / Autopilot filter sidebar
- name: Contact Enrichment
description: >-
Enrich contacts with emails, phone numbers, LinkedIn data, and AI-filled
custom fields
- name: Email Validations
description: Estimate and schedule asynchronous email validation jobs
- name: AI SDR Web Search
description: Find contacts via AI-driven web search and review past searches
- name: Sequences
description: Manage email automation sequences
- name: Sequence Steps
description: Manage individual steps in sequences
- name: Sequence Contacts
description: Manage contacts within sequences
- name: Sequence Folders
description: Organize sequences into folders
- name: Email Accounts
description: Manage email accounts used for sending and receiving
- name: Sequence Email Accounts
description: Manage email accounts linked to sequences
- name: LinkedIn Accounts
description: Manage LinkedIn accounts for outreach
- name: Sequence LinkedIn Accounts
description: Manage LinkedIn accounts linked to sequences
- name: Sequence Templates
description: Manage sequence templates
- name: Email Templates
description: Manage email templates and template folders
- name: Voices
description: Manage cloned voices used for AI voice message steps
- name: Schedules
description: Manage email send schedules and timing
- name: Holiday Calendars
description: Manage holiday calendars for scheduling
- name: Inbox
description: >-
Manage inbox threads — list/filter, read state, replies, category
assignment, and meeting-intent flagging
- name: Inbox Categories
description: Manage per-team inbox thread categories and assign threads to them
- name: Direct Outreach
description: >-
Send one-off outreach directly to a contact outside of any sequence —
direct emails and LinkedIn connection requests, messages, InMails, and
voice messages
- name: Tasks
description: Manage tasks and to-do items
- name: Reports
description: >-
Generate and access performance reports across email, calls, tasks,
LinkedIn, and team performance
- name: AI SDR Sequences
description: >-
Manage AI SDR sequences and their AI SDR-specific settings — create, read
settings, partial update, autopilot enable/disable/force-start, approval
mode, generated step types, and playbook/knowledge-base connections
- name: AI SDR Strategist
description: Trigger AI Strategist runs
- name: AI SDR Playbooks
description: >-
Manage AI SDR playbooks — tone, voice, and style guides applied during
personalized message generation
- name: AI SDR Knowledge Bases
description: >-
Manage AI SDR knowledge bases — collections of documents, links, reply
handlers, and reengagement cards that inform the agent's responses
- name: AI SDR Offers
description: >-
Manage AI SDR offers — bundles of company-context inputs (ICP, pain
points, value propositions, etc.) used to personalize outreach
- name: AI SDR Pending Approvals
description: >-
Review, send, regenerate, and provide feedback on AI-generated messages
awaiting human approval
- name: AI SDR Sequence Preview
description: >-
Read and regenerate per-contact previews of the messages a sequence will
send, and provide feedback on preview messages
- name: AI SDR Insights
description: Read AI SDR insights for sequence contacts
- name: AI SDR Intent Signals
description: >-
Read Reply industry IDs and technology slugs used in AI SDR intent-signal
configuration (typeahead)
- name: AI Prompts
description: >-
Manage the AI prompts used to configure sequence steps, and preview the
output a prompt produces
- name: Registration
description: Register the contact that domain purchases are filed under
- name: Domains
description: Find domains available to buy for outreach
- name: User Account
description: Account information and authentication verification
- name: Settings
description: Manage team and user settings
- name: Billing
description: Subscription details and monthly active contacts usage
- name: Webhooks
description: Manage webhook subscriptions and inspect delivery history
- name: Background Jobs
description: >-
Track and cancel asynchronous background operations (e.g., email
validation)
- name: Attachments
description: >-
Upload file attachments used across email templates, sequence steps, and
direct emails
paths:
/v3/billing:
get:
tags:
- Billing
summary: Get billing details
description: >-
**Coming soon.** This endpoint will be available by early October 2026.
_Requires the `billing:read` scope (or a broader one that
includes it)._
See the plan you are on and how many active contacts the current billing
month has consumed, day by day. A
contact counts once per pool per month, on the day it is first touched.
The `activeContacts` section follows
`billingScope`: under `organization` it holds one pool shared by every
team, with each day split across the
teams you belong to; under `team` it holds one entry per team you can
see, each with its own subscription
and pool. Available to the organization owner, who sees every team, and
to users with the Plans and Billing
permission, who see the teams they belong to.
operationId: GetBillingDetails
responses:
'200':
description: Billing details retrieved successfully
content:
application/json:
schema:
type: object
title: Billing Details
description: >-
The current subscription and the active contacts consumed so
far this billing month.
required:
- generatedAt
- timeZone
- billingScope
- subscription
- activeContacts
properties:
generatedAt:
type: string
format: date-time
description: When this response was produced.
timeZone:
type: string
description: >-
The timezone every date in this response is expressed in.
Always `UTC`.
billingScope:
type: string
title: Billing Scope
description: >-
Whether billing is settled for a whole organization or for
each team on its own. `organization` means every
team draws on one subscription and one shared pool of
active contacts. `team` means each team carries its own
subscription and its own pool.
enum:
- team
- organization
subscription:
allOf:
- type: object
title: Billing Subscription
description: >-
The plan a team is on, and the dates of its current
billing term.
required:
- planName
- planType
- billingPeriod
- planState
- subscriptionState
properties:
planName:
type: string
description: Display name of the plan.
planType:
type: string
description: >-
Plan identifier in camelCase, for example
`businessTier1Annual` or `aiSdrEnterpriseAnnual`.
Treat this as an
opaque string: the catalogue of plans runs to well
over a hundred values and changes as plans are
introduced
and retired.
billingPeriod:
type: string
title: Billing Period
description: How often the subscription renews.
enum:
- unknown
- month
- year
- quarterly
- semiAnnual
planState:
type: string
title: Plan State
description: >-
Where the team sits between trialling Reply and
being a paying customer.
enum:
- trial
- trialExpired
- customer
- closed
- secondTrial
- secondTrialExpired
subscriptionState:
type: string
title: Subscription State
description: >-
The standing of the subscription with the payment
provider.
enum:
- none
- free
- active
- chargeFailure
- suspended
- nonRenewing
- canceled
- underReview
- blocked
startDate:
type: string
format: date-time
nullable: true
description: >-
Start of the current billing term. For a team
still trialling Reply and with no subscription
yet, this is
the start of the trial window instead.
endDate:
type: string
format: date-time
nullable: true
description: >-
End of the current billing term. For a team still
trialling Reply and with no subscription yet, this
is the
date the trial expires instead.
nextBillingDate:
type: string
format: date-time
nullable: true
description: >-
When the subscription is next charged. Null when
it does not renew, or when there is no
subscription yet.
description: >-
The subscription the figures are billed against. Under
`organization` scope this is the subscription held by
the organization owner's team; under `team` scope it is
your own team's.
activeContacts:
type: object
title: Active Contacts Billing
description: >-
Active contacts usage, shaped by `billingScope`. Exactly
one of the two properties carries data: `organization`
when the scope is `organization`, `teams` when it is
`team`. The other is null.
properties:
organization:
allOf:
- type: object
title: Active Contacts Usage
description: >-
Active contacts consumed in the current billing
month, with a day-by-day breakdown. A contact
counts once per
pool per month, on the day it is first touched,
however many times it is contacted afterwards.
required:
- billingMonthStart
- billingMonthEnd
- poolType
- aiSdrContactsIncluded
- computedAt
- used
- daily
properties:
billingMonthStart:
type: string
format: date-time
description: First day of the current billing month.
billingMonthEnd:
type: string
format: date-time
description: >-
Exclusive end of the current billing month,
which is the first day of the next one.
poolType:
type: string
title: Active Contacts Pool Type
description: >-
How the monthly active contacts allowance is
measured. `shared` is a single capped pool,
and is the only value
for which `available` and `remaining` carry a
number. `unlimited` is a shared pool with no
cap. `perUser` means
the plan meters contacts against each user
rather than from a shared pool.
enum:
- shared
- unlimited
- perUser
aiSdrContactsIncluded:
type: boolean
description: >-
Whether contacts touched by AI SDR sequences
draw on this pool. Determined by the plan.
computedAt:
type: string
format: date-time
description: >-
When the daily figures were calculated. They
are cached for up to 30 minutes, so this can
be earlier than
`generatedAt`.
available:
type: integer
nullable: true
description: >-
Size of the pool for the month. Null unless
`poolType` is `shared`.
used:
type: integer
description: Contacts consumed so far this billing month.
remaining:
type: integer
nullable: true
description: >-
`available` minus `used`, never below zero.
Null unless `poolType` is `shared`.
daily:
type: array
description: >-
One entry per day, from the first day of the
billing month through today. Days still to
come in the month
are not included.
items:
type: object
title: Active Contacts Daily Usage
description: >-
Active contacts for one day of the billing
month.
required:
- date
- used
- cumulativeUsed
properties:
date:
type: string
format: date-time
description: >-
The day these figures cover, at midnight
UTC.
used:
type: integer
description: Contacts first touched on this day.
cumulativeUsed:
type: integer
description: >-
Running total from the first day of the
billing month through this day.
remaining:
type: integer
nullable: true
description: >-
What is left of the pool after this day,
never below zero. Null unless `poolType`
is `shared`.
teams:
type: array
nullable: true
description: >-
How this day's `used` splits across
teams, limited to the teams you can see.
Present when `billingScope` is
`organization`, and null otherwise. A
day on which no visible team touched a
contact returns an empty array.
items:
type: object
title: Team Daily Active Contacts
description: >-
One team's share of the contacts first
touched on a single day.
required:
- teamId
- teamName
- used
properties:
teamId:
type: integer
description: The team (workspace) ID.
teamName:
type: string
description: The team (workspace) name.
used:
type: integer
description: >-
Contacts attributed to this team on that
day.
nullable: true
description: >-
The single pool shared by every team in the
organization. Null when `billingScope` is `team`.
teams:
type: array
nullable: true
description: >-
One entry per team you can see, each with its own
subscription and pool. Null when `billingScope` is
`organization`. Teams without an active owner are left
out.
items:
type: object
title: Team Active Contacts Usage
description: >-
One team's own subscription and active contacts
usage.
required:
- teamId
- teamName
- subscription
- usage
properties:
teamId:
type: integer
description: The team (workspace) ID.
teamName:
type: string
description: The team (workspace) name.
subscription:
type: object
title: Billing Subscription
description: >-
The plan a team is on, and the dates of its
current billing term.
required:
- planName
- planType
- billingPeriod
- planState
- subscriptionState
properties:
planName:
type: string
description: Display name of the plan.
planType:
type: string
description: >-
Plan identifier in camelCase, for example
`businessTier1Annual` or
`aiSdrEnterpriseAnnual`. Treat this as an
opaque string: the catalogue of plans runs
to well over a hundred values and changes as
plans are introduced
and retired.
billingPeriod:
type: string
title: Billing Period
description: How often the subscription renews.
enum:
- unknown
- month
- year
- quarterly
- semiAnnual
planState:
type: string
title: Plan State
description: >-
Where the team sits between trialling Reply
and being a paying customer.
enum:
- trial
- trialExpired
- customer
- closed
- secondTrial
- secondTrialExpired
subscriptionState:
type: string
title: Subscription State
description: >-
The standing of the subscription with the
payment provider.
enum:
- none
- free
- active
- chargeFailure
- suspended
- nonRenewing
- canceled
- underReview
- blocked
startDate:
type: string
format: date-time
nullable: true
description: >-
Start of the current billing term. For a
team still trialling Reply and with no
subscription yet, this is
the start of the trial window instead.
endDate:
type: string
format: date-time
nullable: true
description: >-
End of the current billing term. For a team
still trialling Reply and with no
subscription yet, this is the
date the trial expires instead.
nextBillingDate:
type: string
format: date-time
nullable: true
description: >-
When the subscription is next charged. Null
when it does not renew, or when there is no
subscription yet.
usage:
type: object
title: Active Contacts Usage
description: >-
Active contacts consumed in the current billing
month, with a day-by-day breakdown. A contact
counts once per
pool per month, on the day it is first touched,
however many times it is contacted afterwards.
required:
- billingMonthStart
- billingMonthEnd
- poolType
- aiSdrContactsIncluded
- computedAt
- used
- daily
properties:
billingMonthStart:
type: string
format: date-time
description: First day of the current billing month.
billingMonthEnd:
type: string
format: date-time
description: >-
Exclusive end of the current billing month,
which is the first day of the next one.
poolType:
type: string
title: Active Contacts Pool Type
description: >-
How the monthly active contacts allowance is
measured. `shared` is a single capped pool,
and is the only value
for which `available` and `remaining` carry
a number. `unlimited` is a shared pool with
no cap. `perUser` means
the plan meters contacts against each user
rather than from a shared pool.
enum:
- shared
- unlimited
- perUser
aiSdrContactsIncluded:
type: boolean
description: >-
Whether contacts touched by AI SDR sequences
draw on this pool. Determined by the plan.
computedAt:
type: string
format: date-time
description: >-
When the daily figures were calculated. They
are cached for up to 30 minutes, so this can
be earlier than
`generatedAt`.
available:
type: integer
nullable: true
description: >-
Size of the pool for the month. Null unless
`poolType` is `shared`.
used:
type: integer
description: Contacts consumed so far this billing month.
remaining:
type: integer
nullable: true
description: >-
`available` minus `used`, never below zero.
Null unless `poolType` is `shared`.
daily:
type: array
description: >-
One entry per day, from the first day of the
billing month through today. Days still to
come in the month
are not included.
items:
type: object
title: Active Contacts Daily Usage
description: >-
Active contacts for one day of the billing
month.
required:
- date
- used
- cumulativeUsed
properties:
date:
type: string
format: date-time
description: >-
The day these figures cover, at midnight
UTC.
used:
type: integer
description: Contacts first touched on this day.
cumulativeUsed:
type: integer
description: >-
Running total from the first day of the
billing month through this day.
remaining:
type: integer
nullable: true
description: >-
What is left of the pool after this day,
never below zero. Null unless `poolType`
is `shared`.
teams:
type: array
nullable: true
description: >-
How this day's `used` splits across
teams, limited to the teams you can see.
Present when `billingScope` is
`organization`, and null otherwise. A
day on which no visible team touched a
contact returns an empty array.
items:
type: object
title: Team Daily Active Contacts
description: >-
One team's share of the contacts first
touched on a single day.
required:
- teamId
- teamName
- used
properties:
teamId:
type: integer
description: The team (workspace) ID.
teamName:
type: string
description: The team (workspace) name.
used:
type: integer
description: >-
Contacts attributed to this team on that
day.
'401':
description: >-
Unauthorized. The response body is empty; check the
`WWW-Authenticate` header for the expected scheme.
content:
application/problem+json:
schema:
allOf:
- type: object
title: Problem Details
description: >-
Bare RFC 9457 problem-details envelope. Returned by
middleware-level errors
that don't carry domain context: 401 Unauthorized (auth
middleware),
429 Too Many Requests (rate-limit middleware), and
route-level 404 / 405 /
415 (framework middleware).
Business and validation responses extend this envelope and
add additional
fields — see `business-problem.model.yaml` (adds `code`
slug) and
`validation-problem.model.yaml` (adds `errors[]` array).
properties:
title:
type: string
description: Short, human-readable summary of the problem.
status:
type: integer
description: HTTP status code.
minimum: 100
maximum: 599
detail:
type: string
description: >-
Human-readable explanation specific to this
occurrence.
- example:
title: Unauthorized
status: 401
detail: Authentication credentials are missing or invalid.
'403':
description: >-
Billing is not enabled for the caller's team, or the caller is
neither the organization owner nor a user with the Plans and Billing
permission
content:
application/problem+json:
schema:
allOf:
- allOf:
- type: object
title: Problem Details
description: >-
Bare RFC 9457 problem-details envelope. Returned by
middleware-level errors
that don't carry domain context: 401 Unauthorized
(auth middleware),
429 Too Many Requests (rate-limit middleware), and
route-level 404 / 405 /
415 (framework middleware).
Business and validation responses extend this envelope
and add additional
fields — see `business-problem.model.yaml` (adds
`code` slug) and
`validation-problem.model.yaml` (adds `errors[]`
array).
properties:
title:
type: string
description: Short, human-readable summary of the problem.
status:
type: integer
description: HTTP status code.
minimum: 100
maximum: 599
detail:
type: string
description: >-
Human-readable explanation specific to this
occurrence.
- type: object
properties:
code:
type: string
description: >-
Stable, machine-readable error slug in the form
`"."`.
* `resource` is the camelCased domain — e.g.
`sequence`,
`contact`, `inboxThread`, `blacklistDomainRule`.
* `variant` is the camelCased specific failure
mode — e.g.
`notFound`, `forbidden`, `duplicateName`, `globalRuleReadOnly`.
Use `code` for programmatic error handling; use
`detail` for
user-facing messages. Slugs are stable across
server-side enum
reorderings and never change meaning under a given
resource.
pattern: ^[a-z][a-zA-Z0-9]*(\.[a-z][a-zA-Z0-9]*)+$
example: sequence.notFound
title: Business Problem
description: >-
Domain error response carrying a stable, namespaced error
slug.
Emitted for most 4xx responses (business 400, 403, 404,
409, …) and
for 503 when a downstream dependency is unavailable.
- example:
title: Forbidden
status: 403
detail: You do not have permission to access this resource.
code: sequence.forbidden
examples:
featureDisabled:
summary: Billing is not enabled for the team
value:
title: Forbidden
status: 403
detail: Billing API is not available for your team.
code: billing.featureDisabled
forbidden:
summary: Caller lacks billing access
value:
title: Forbidden
status: 403
detail: >-
Billing details are available to the organization owner or
to users with the Plans and Billing permission.
code: billing.forbidden
'404':
description: The caller's team has no payment plan
content:
application/problem+json:
schema:
allOf:
- allOf:
- type: object
title: Problem Details
description: >-
Bare RFC 9457 problem-details envelope. Returned by
middleware-level errors
that don't carry domain context: 401 Unauthorized
(auth middleware),
429 Too Many Requests (rate-limit middleware), and
route-level 404 / 405 /
415 (framework middleware).
Business and validation responses extend this envelope
and add additional
fields — see `business-problem.model.yaml` (adds
`code` slug) and
`validation-problem.model.yaml` (adds `errors[]`
array).
properties:
title:
type: string
description: Short, human-readable summary of the problem.
status:
type: integer
description: HTTP status code.
minimum: 100
maximum: 599
detail:
type: string
description: >-
Human-readable explanation specific to this
occurrence.
- type: object
properties:
code:
type: string
description: >-
Stable, machine-readable error slug in the form
`"."`.
* `resource` is the camelCased domain — e.g.
`sequence`,
`contact`, `inboxThread`, `blacklistDomainRule`.
* `variant` is the camelCased specific failure
mode — e.g.
`notFound`, `forbidden`, `duplicateName`, `globalRuleReadOnly`.
Use `code` for programmatic error handling; use
`detail` for
user-facing messages. Slugs are stable across
server-side enum
reorderings and never change meaning under a given
resource.
pattern: ^[a-z][a-zA-Z0-9]*(\.[a-z][a-zA-Z0-9]*)+$
example: sequence.notFound
title: Business Problem
description: >-
Domain error response carrying a stable, namespaced error
slug.
Emitted for most 4xx responses (business 400, 403, 404,
409, …) and
for 503 when a downstream dependency is unavailable.
- example:
title: Not Found
status: 404
detail: The requested resource was not found.
code: sequence.notFound
example:
title: Not Found
status: 404
detail: No payment plan is available for this team.
code: billing.notFound
'429':
description: Too Many Requests
headers:
Retry-After:
description: Seconds to wait before retrying
schema:
type: integer
minimum: 1
content:
application/problem+json:
schema:
allOf:
- type: object
title: Problem Details
description: >-
Bare RFC 9457 problem-details envelope. Returned by
middleware-level errors
that don't carry domain context: 401 Unauthorized (auth
middleware),
429 Too Many Requests (rate-limit middleware), and
route-level 404 / 405 /
415 (framework middleware).
Business and validation responses extend this envelope and
add additional
fields — see `business-problem.model.yaml` (adds `code`
slug) and
`validation-problem.model.yaml` (adds `errors[]` array).
properties:
title:
type: string
description: Short, human-readable summary of the problem.
status:
type: integer
description: HTTP status code.
minimum: 100
maximum: 599
detail:
type: string
description: >-
Human-readable explanation specific to this
occurrence.
example:
title: Too Many Requests
status: 429
detail: API calls quota exceeded! maximum admitted 100 per 1m.
components:
securitySchemes:
bearerAuth:
type: http
scheme: bearer
description: >-
Authenticate every request with a Bearer token. Pass your Reply API key
in the
`Authorization` header:
```
Authorization: Bearer
```
Get your API key from the Reply dashboard: **Settings → API Key**.
````