> ## 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.
# List changed inbox threads
>
**Coming soon.** This endpoint will be available by mid November 2026.
_Requires the `inbox:read` scope (or a broader one that includes it)._
Use this endpoint to follow which inbox threads changed without re-listing the inbox. It returns threads in the order they were changed, earliest change first, and you read it forward with a cursor. A thread appears each time it changes: a new message, inbound or outbound, including one synced late; marking it read or unread; a meeting intent change; an owner change; its deletion from the inbox. Changing a thread's category alone does not return it; the `category` on each item, and `hasMeetingIntent`, which also follows the category, are the thread's values at the time of the read. Each item carries the thread's latest message, so you can tell a contact's reply from your own send. You see the same threads as in the thread list.
`lastActivityDate` is the date of the message that last moved the thread, at the same 10 ms precision as the message dates; nothing else moves it (not category, meeting intent, viewed, owner or delete changes). For a thread whose latest message is an email or a LinkedIn message, it equals `lastMessage.date`; it can be later when the latest message is an SMS, which `lastMessage` does not carry.
`isDeleted` true means the thread was deleted; the change reported is the deletion, and `GET /v3/inbox/threads/{id}` answers 404 for it. A thread removed together with its contact, its sequence enrolment or its team is not reported; `GET /v3/inbox/threads/{id}` answering 404 is how you learn of it.
A change of who may see a thread is not a change of the thread: a thread moved to another owner is not reported to a reader who saw it only as the previous owner's, and threads that become visible to you through a sequence or contact owner change are not returned until they change again. After a change of your role, of ownership or of your team, read again with `since`.
Start a read in one of three ways: pass the `cursor` from a previous page; pass `since` to start from the threads whose last activity is at or after that moment (at most 30 days ago); or pass neither to start from the last 30 days. Pass `cursor` or `since`, not both. A read started from `since` or with no parameters first returns the threads that moved in that window, oldest first, by the moment the thread moved, deleted threads excluded: a thread deleted before the read is not listed. The window lists only live threads: a thread you hold whose last activity is at or after the window's start and that the window does not return was deleted or is no longer visible to you, and for a thread whose last activity is before the window's start the window says nothing (only a message moves `lastActivityDate`, so a deletion does not bring a thread into the window). Deletions are reported only by the changes you read by cursor (`isDeleted`), so a read started again does not report the deletions made since your last cursor; confirm a thread you hold with `GET /v3/inbox/threads/{id}`, which answers 404 for a deleted one. It then continues with the changes made since the read began, by cursor like any later read: a thread written, moved or deleted while the window was being read arrives there, whatever its last activity, so it can appear twice.
The cursor is a position in the sequence of changes, not a time. Keep calling with the returned `cursor` while `hasMore` is true; read until `hasMore` is false, not until a page is empty, because a page can be empty with `hasMore` true: while the read passes threads it does not return (threads you cannot see, or deleted threads in the window), and when it reaches the end of the window, as when the window's last thread was deleted while it was being read. When `hasMore` is false, store the cursor and call again later: the next call returns every change made after the page was read, and none is skipped. An empty page with `hasMore` false returns a cursor at the feed's current position, never behind the one you passed. A change becomes readable once every write in progress before it has finished, so a long-running write anywhere in Reply can hold the feed back for every team until it completes; nothing is lost while it waits. Delivery is at least once: a thread can come back after a cursor that already covered it, so process each item as the thread's current state, keyed on `threadId`.
A cursor ahead of the feed's current position (as after a restore of the service's data), or a `since` older than 30 days, is refused with 400 and the code `inboxThread.changeWindowExpired`; start again with `since` or with no parameters.
## OpenAPI
````yaml /api-reference/bundled.yaml get /v3/inbox/threads/changes
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, sequence structure, and playbook/knowledge-base connections
- name: AI SDR Sequence Structures
description: >-
Browse the sequence structures — reusable outlines of AI SDR sequence
steps — that can be applied to AI SDR sequences
- 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: AI SDR Learnings
description: >-
Manage the standing rules that shape how the AI writes — list, read,
create, partially update and delete AI learnings
- name: Registration
description: Register the contact that domain purchases are filed under
- name: Domains
description: Find domains available to buy for outreach
- name: Purchased Domains
description: >-
List the domains your team bought, with their subscription, setup and
renewal state, and renew them
- name: Pre-warmed Domains
description: >-
Find pre-warmed domains on sale, with mailboxes that are already warming,
and list the ones your team bought
- name: Mailboxes
description: >-
Add mailboxes to domains your team already bought, priced before you
order, and reconnect them
- name: User Account
description: Account information and authentication verification
- name: Teams
description: Add existing users of your organization to its teams
- name: Settings
description: Manage team and user settings
- name: Billing
description: Subscription details and monthly active contacts usage
- name: Rate Limits
description: Your API rate limits, your current usage and the packages that raise them
- name: Support Requests
description: Raise and follow support requests with Reply's support team
- 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/inbox/threads/changes:
get:
tags:
- Inbox
summary: List changed inbox threads
description: >-
**Coming soon.** This endpoint will be available by mid November 2026.
_Requires the `inbox:read` scope (or a broader one that includes
it)._
Use this endpoint to follow which inbox threads changed without
re-listing the inbox. It returns threads in the order they were changed,
earliest change first, and you read it forward with a cursor. A thread
appears each time it changes: a new message, inbound or outbound,
including one synced late; marking it read or unread; a meeting intent
change; an owner change; its deletion from the inbox. Changing a
thread's category alone does not return it; the `category` on each item,
and `hasMeetingIntent`, which also follows the category, are the
thread's values at the time of the read. Each item carries the thread's
latest message, so you can tell a contact's reply from your own send.
You see the same threads as in the thread list.
`lastActivityDate` is the date of the message that last moved the
thread, at the same 10 ms precision as the message dates; nothing else
moves it (not category, meeting intent, viewed, owner or delete
changes). For a thread whose latest message is an email or a LinkedIn
message, it equals `lastMessage.date`; it can be later when the latest
message is an SMS, which `lastMessage` does not carry.
`isDeleted` true means the thread was deleted; the change reported is
the deletion, and `GET /v3/inbox/threads/{id}` answers 404 for it. A
thread removed together with its contact, its sequence enrolment or its
team is not reported; `GET /v3/inbox/threads/{id}` answering 404 is how
you learn of it.
A change of who may see a thread is not a change of the thread: a thread
moved to another owner is not reported to a reader who saw it only as
the previous owner's, and threads that become visible to you through a
sequence or contact owner change are not returned until they change
again. After a change of your role, of ownership or of your team, read
again with `since`.
Start a read in one of three ways: pass the `cursor` from a previous
page; pass `since` to start from the threads whose last activity is at
or after that moment (at most 30 days ago); or pass neither to start
from the last 30 days. Pass `cursor` or `since`, not both. A read
started from `since` or with no parameters first returns the threads
that moved in that window, oldest first, by the moment the thread moved,
deleted threads excluded: a thread deleted before the read is not
listed. The window lists only live threads: a thread you hold whose last
activity is at or after the window's start and that the window does not
return was deleted or is no longer visible to you, and for a thread
whose last activity is before the window's start the window says nothing
(only a message moves `lastActivityDate`, so a deletion does not bring a
thread into the window). Deletions are reported only by the changes you
read by cursor (`isDeleted`), so a read started again does not report
the deletions made since your last cursor; confirm a thread you hold
with `GET /v3/inbox/threads/{id}`, which answers 404 for a deleted one.
It then continues with the changes made since the read began, by cursor
like any later read: a thread written, moved or deleted while the window
was being read arrives there, whatever its last activity, so it can
appear twice.
The cursor is a position in the sequence of changes, not a time. Keep
calling with the returned `cursor` while `hasMore` is true; read until
`hasMore` is false, not until a page is empty, because a page can be
empty with `hasMore` true: while the read passes threads it does not
return (threads you cannot see, or deleted threads in the window), and
when it reaches the end of the window, as when the window's last thread
was deleted while it was being read. When `hasMore` is false, store the
cursor and call again later: the next call returns every change made
after the page was read, and none is skipped. An empty page with
`hasMore` false returns a cursor at the feed's current position, never
behind the one you passed. A change becomes readable once every write in
progress before it has finished, so a long-running write anywhere in
Reply can hold the feed back for every team until it completes; nothing
is lost while it waits. Delivery is at least once: a thread can come
back after a cursor that already covered it, so process each item as the
thread's current state, keyed on `threadId`.
A cursor ahead of the feed's current position (as after a restore of the
service's data), or a `since` older than 30 days, is refused with 400
and the code `inboxThread.changeWindowExpired`; start again with `since`
or with no parameters.
operationId: ListChangedInboxThreads
parameters:
- in: query
name: cursor
schema:
type: string
description: Opaque cursor from a previous page. Pass it back unchanged.
- in: query
name: since
schema:
type: string
format: date-time
description: >-
Start of the read, inclusive - the threads whose last activity is at
or after this moment. At most 30 days ago and at most 5 minutes
ahead of the server's clock. Cannot be combined with `cursor`.
- in: query
name: top
schema:
type: integer
minimum: 1
maximum: 1000
description: >-
Maximum items to return. Defaults to the server-side default page
size when omitted.
responses:
'200':
description: Page of changed inbox threads
content:
application/json:
schema:
type: object
required:
- items
- hasMore
- cursor
properties:
items:
type: array
items:
type: object
title: Inbox Thread Change
description: One changed inbox thread, as of its latest activity.
required:
- threadId
- contactId
- channel
- lastActivityDate
- isDeleted
- hasMeetingIntent
- flags
properties:
threadId:
type: integer
description: >-
Inbox thread id, the same id the thread endpoints
take.
contactId:
type: integer
description: Id of the contact the thread is with.
channel:
type: string
enum:
- unknown
- email
- linkedIn
description: >-
Channel of the thread. SMS threads come as `unknown`
and carry no `lastMessage`.
lastActivityDate:
type: string
format: date-time
description: >-
`lastActivityDate` is the date of the message that
last moved the thread, at the same 10 ms precision
as the message dates; nothing else moves it (not
category, meeting intent, viewed, owner or delete
changes). For a thread whose latest message is an
email or a LinkedIn message, it equals
`lastMessage.date`; it can be later when the latest
message is an SMS, which `lastMessage` does not
carry. In UTC.
isDeleted:
type: boolean
description: >-
True when the thread was deleted: the change
reported is the deletion, and `GET
/v3/inbox/threads/{id}` answers 404 for it. A thread
removed together with its contact, its sequence
enrolment or its team is not reported.
sequenceId:
type: integer
nullable: true
description: >-
Sequence the thread belongs to; absent for threads
outside a sequence.
category:
type: object
allOf:
- type: object
title: Inbox Thread Category Reference
description: >-
Minimal category reference embedded in thread
responses.
required:
- id
- name
properties:
id:
type: integer
name:
type: string
nullable: true
hasMeetingIntent:
type: boolean
description: >-
True when the thread has meeting intent, from its
meeting intent flag or its category.
flags:
type: object
title: Inbox Thread Change Flags
description: >-
What the thread has received so far. Each flag stays
true once set.
required:
- hasReply
- hasBounce
- hasAutoReply
- hasOutOfOffice
properties:
hasReply:
type: boolean
description: The contact has replied.
hasBounce:
type: boolean
description: A message in the thread has bounced.
hasAutoReply:
type: boolean
description: An automatic reply has arrived.
hasOutOfOffice:
type: boolean
description: An out-of-office reply has arrived.
lastMessage:
type: object
allOf:
- type: object
title: Inbox Thread Change Last Message
description: The latest message in the thread.
required:
- isOutbound
- date
properties:
messageId:
type: string
nullable: true
description: >-
The message id, which is the `Message-ID`
header for email and the message identifier
for LinkedIn. For LinkedIn messages this
feed is where the id is available; `GET
/v3/inbox/threads/{id}/messages` returns
`messageId` as null for them.
isOutbound:
type: boolean
description: >-
True when the message was sent from your
side, false when it came from the contact.
date:
type: string
format: date-time
nullable: true
description: >-
The thread's latest message; absent when it cannot
be resolved.
hasMore:
type: boolean
description: >-
True when more changes are ready to read now; call again
with `cursor`. A page can be empty while this is true.
cursor:
type: string
description: >-
Position after this page in the sequence of changes. Send
it as `cursor` on the next call.
examples:
reply_then_send:
summary: A contact's reply, then your own send on another thread
value:
items:
- threadId: 58217
contactId: 9821
channel: email
lastActivityDate: '2026-11-03T14:32:11.27Z'
isDeleted: false
sequenceId: 314
category:
id: 7
name: Hot Leads
hasMeetingIntent: true
flags:
hasReply: true
hasBounce: false
hasAutoReply: false
hasOutOfOffice: false
lastMessage:
messageId:
isOutbound: false
date: '2026-11-03T14:32:11.27Z'
- threadId: 58198
contactId: 9744
channel: linkedIn
lastActivityDate: '2026-11-03T14:40:02.5Z'
isDeleted: false
hasMeetingIntent: false
flags:
hasReply: true
hasBounce: false
hasAutoReply: false
hasOutOfOffice: false
lastMessage:
messageId: 3f0c9a52-6d1e-4b8a-9c2f-71e5a0b4d913
isOutbound: true
date: '2026-11-03T14:40:02.5Z'
hasMore: false
cursor: AgAAAAAaKzxN
empty:
summary: Nothing new since the cursor
value:
items: []
hasMore: false
cursor: AgAAAAAaKz0Q
'400':
description: >-
Parameter validation failure (an unreadable cursor, both `cursor`
and `since`, or a `since` more than 5 minutes ahead of the server's
clock); a cursor ahead of the feed's current position, or a `since`
older than 30 days (code `inboxThread.changeWindowExpired`); or
invalid pagination (code `inboxThread.invalidPagination`).
content:
application/problem+json:
schema:
oneOf:
- 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:
errors:
type: array
description: >-
List of field-level validation errors. Always
non-empty when this
envelope is returned. Each entry pins a single
offending field
via JSON Pointer plus a sanitized detail
string.
items:
type: object
title: Validation Error
description: A single field-level validation error.
properties:
pointer:
type: string
description: >-
JSON Pointer (RFC 6901) to the offending
field — e.g.
`/steps/0/subject`.
* An empty string (`""`) means the error
applies to the whole
request body (e.g. body is missing or unparseable).
* For route or query parameter failures
the pointer is the parameter
name (e.g. `id`, `top`).
example: /steps/0/subject
detail:
type: string
description: >-
Sanitized, human-readable explanation of
this field's error. One of a
small set of templates — `"Field is
required."`, `"Value has an
invalid type."`, `"Value has an invalid
format."`, `"Request body is
not valid JSON."`, `"The request body is
required and cannot be
empty."` — or a FluentValidator message
on body endpoints.
example: Field is required.
title: Validation Problem
description: >-
Input-validation error response at 400. Returned when
the request body
fails binding, FluentValidator rules, or when
route/query parameter
attribute validation (`[Range]`, `[Required]`) fails.
Route, query, and
body errors are combined into a single `errors[]`
array — clients should
not assume one error per request.
- example:
title: Validation failed
status: 400
detail: The request body contains validation errors.
errors:
- pointer: /name
detail: Field is required.
- 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: Bad Request
status: 400
detail: Pagination parameters are invalid.
code: sequence.invalidPagination
examples:
cursor_and_since:
summary: Both cursor and since
value:
title: Validation failed
status: 400
detail: The request body contains validation errors.
errors:
- pointer: /since
detail: Pass either 'cursor' or 'since', not both.
business_change_window_expired:
summary: since older than 30 days
value:
title: Bad Request
status: 400
detail: >-
'since' must be at most 30 days ago. Start again with
'since' (at most 30 days ago) or with no parameters, which
reads the last 30 days.
code: inboxThread.changeWindowExpired
business_cursor_ahead:
summary: Cursor ahead of the feed's current position
value:
title: Bad Request
status: 400
detail: >-
'cursor' is ahead of this feed's current position. Start
again with 'since' (at most 30 days ago) or with no
parameters, which reads the last 30 days.
code: inboxThread.changeWindowExpired
business_invalid_pagination:
summary: Invalid pagination
value:
title: Bad Request
status: 400
detail: Parameter 'top' must be between 1 and 1000
code: inboxThread.invalidPagination
'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: Inbox feature is not available for this user or team.
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
example:
title: Forbidden
status: 403
detail: You do not have permission to access the inbox.
code: inboxThread.forbidden
'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**.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.