> ## 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.
# Cancel a direct send
>
**Coming soon.** This endpoint will be available by mid November 2026.
_Requires the `contacts:operate` scope (or a broader one that includes it)._
Cancel a direct send that is still `queued` or `waitingForSchedule`, by its `reference`, or a LinkedIn send for later (`linkedin-scheduled-`) that is `sending` but still waits in the account's queue. Answers the send in the `cancelled` state. Cancelling a send already cancelled answers it again, so the call is safe to repeat.
A send that is `sending` or `sent` answers 409 `directSend.alreadySent`, and one that has `failed` answers 409 `directSend.alreadyFailed`. A LinkedIn send for later (`linkedin-scheduled-`) that is being handed to the account's queue, or that the account has started, answers 409 `directSend.alreadySending`. A send can start the moment it is due, so a cancel made very close to `sendAfter` may find it already gone.
An unconfirmed cancel of a send not yet gone answers 503 `directSend.cancelNotConfirmed`; retry it. For a LinkedIn send for later that also covers one being picked up at that moment while it still reads `queued` or `waitingForSchedule`, and one waiting in the account's queue whose cancel met a concurrent change.
An email send made by a teammate can be cancelled when you may act for that teammate, otherwise it answers 403 `directSend.notOwned`. A LinkedIn send can be cancelled by every teammate who can see its LinkedIn account.
## OpenAPI
````yaml /api-reference/bundled.yaml post /v3/direct-sends/{reference}/cancel
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/direct-sends/{reference}/cancel:
post:
tags:
- Direct Outreach
summary: Cancel a direct send
description: >-
**Coming soon.** This endpoint will be available by mid November 2026.
_Requires the `contacts:operate` scope (or a broader one that
includes it)._
Cancel a direct send that is still `queued` or `waitingForSchedule`, by
its `reference`, or a LinkedIn send for later
(`linkedin-scheduled-`) that is `sending` but still waits in the
account's queue. Answers the send in the `cancelled` state. Cancelling a
send already cancelled answers it again, so the call is safe to repeat.
A send that is `sending` or `sent` answers 409 `directSend.alreadySent`,
and one that has `failed` answers 409 `directSend.alreadyFailed`. A
LinkedIn send for later (`linkedin-scheduled-`) that is being handed
to the account's queue, or that the account has started, answers 409
`directSend.alreadySending`. A send can start the moment it is due, so a
cancel made very close to `sendAfter` may find it already gone.
An unconfirmed cancel of a send not yet gone answers 503
`directSend.cancelNotConfirmed`; retry it. For a LinkedIn send for later
that also covers one being picked up at that moment while it still reads
`queued` or `waitingForSchedule`, and one waiting in the account's queue
whose cancel met a concurrent change.
An email send made by a teammate can be cancelled when you may act for
that teammate, otherwise it answers 403 `directSend.notOwned`. A
LinkedIn send can be cancelled by every teammate who can see its
LinkedIn account.
operationId: CancelDirectSend
parameters:
- name: reference
in: path
required: true
description: >-
The send's reference, `email-`, `linkedin-` or
`linkedin-scheduled-`. A reference not of this form answers 404
`directSend.notFound`.
schema:
type: string
responses:
'200':
description: The send, cancelled.
content:
application/json:
schema:
type: object
title: Direct Send
description: >-
One direct send - an email or a LinkedIn action sent to a
contact outside any sequence - read by its reference.
required:
- reference
- channel
- contactId
- state
- sendAfter
properties:
reference:
type: string
description: >-
The reference the send route answered with, `email-`,
`linkedin-` or `linkedin-scheduled-`. Treat it as
opaque.
example: email-48213
channel:
type: string
title: Direct Send Channel
description: The channel a direct send goes out on.
enum:
- email
- linkedIn
contactId:
type: integer
description: ID of the contact the send is addressed to.
state:
type: string
title: Direct Send State
description: >-
Where a direct send stands.
| Value | Meaning |
|---|---|
| `queued` | Accepted and waiting for its moment; it can
still be cancelled. |
| `waitingForSchedule` | Accepted and waiting for its
schedule to open, more than ten minutes after acceptance;
`estimatedSendAt` says when. A schedule open sooner queues
the send at once (`queued`). It can still be cancelled. |
| `sending` | Being sent right now - for a LinkedIn send,
handed to the account's queue and waiting or running
there. It can no longer be cancelled, except a LinkedIn
send for later that waits in the account's queue and has
not been started. |
| `sent` | Gone out. |
| `failed` | Did not go out, or its outcome is unknown;
`failureCode` and `failureReason` say why. |
| `cancelled` | Cancelled while queued; it will not go
out. |
enum:
- queued
- waitingForSchedule
- sending
- sent
- failed
- cancelled
sendAfter:
type: string
format: date-time
nullable: true
description: >-
UTC moment after which the send is attempted - the
requested `sendAfter`, when the send was accepted, or the
schedule opening it was queued for. Null while the send
waits for its schedule; `estimatedSendAt` is set then. A
send cancelled while waiting, or failed because its
schedule or the contact's time zone was gone, reads the
requested `sendAfter` when it was given one, and null when
it was made with a schedule and no `sendAfter` - it was
never given a moment. This holds for email and LinkedIn
alike.
estimatedSendAt:
type: string
format: date-time
nullable: true
description: >-
When the schedule the send waits for next opens, as read
now; the send goes out within about 10 minutes of it. A
schedule open at acceptance or opening within the next ten
minutes queued the send for that moment at once, so it
reads `queued` with `sendAfter` and this null. Set in the
`waitingForSchedule` state only, and null there when the
schedule does not open within 30 days of the moment the
send waits from (the requested `sendAfter`, or now once
that has passed).
sentAt:
type: string
format: date-time
nullable: true
description: >-
UTC moment the send went out. Set in the `sent` state
only.
messageId:
type: string
nullable: true
description: >-
Message-ID of the email once it has gone out. Always null
for LinkedIn.
failureCode:
type: string
nullable: true
description: >-
What the failure was, as the `code` the send route answers
that failure with. Set in the `failed` state when the
failure has a code of its own; null otherwise, and then
`failureReason` tells it.
| Value | Meaning |
|---|---|
| `contact.missingVariables` | The email's template uses
variables that have no value for the contact;
`missingVariables` names them. Nothing went out. |
| `contact.renderingFailed` | The email's template could
not be rendered for the contact. Nothing went out. |
| `contact.notFound` | The contact has no valid email
address. Nothing went out. |
| `contact.contactInBlackList` | The contact is on the
blacklist. Nothing went out. |
| `contact.scheduleNotFound` | The schedule the send
waited for was deleted. Nothing went out. |
| `contact.scheduleHasNoSlot` | The schedule the send
waited for was left with no active day that has a time
range, so it never opens. Nothing went out. |
| `contact.contactTimeZoneMissing` | The send waited for
its schedule in the contact's time zone
(`useContactTimeZone` `true`), and the contact no longer
has one. Nothing went out. |
| `directSend.dispatchWindowMissed` | The send was never
attempted: its moment passed without it being picked up.
Nothing went out; sending again is safe. |
| `directSend.dispatchInterrupted` | The send was
attempted but its outcome is unknown. It may have gone
out; check before sending again. |
| `directLinkedIn.weeklyLimitReached` | LinkedIn is
limiting the account's connection requests, or refused
this one for the account's limit; for a send for later,
the limit outlasted its retry window. Nothing went out;
send again once the account is no longer limited. |
| `directLinkedIn.dailyLimitReached` | A LinkedIn send for
later stayed blocked by the account's daily allowance for
the action until its retry window ended. Nothing went out.
|
| `directLinkedIn.missedWindow` | A LinkedIn send for
later was due while nothing could hand it to the account's
queue, and its retry window ended first. Nothing went out;
sending again is safe. |
| `directLinkedIn.scheduleNotFound` | The schedule a
LinkedIn send waited for was deleted. Nothing went out. An
email send reads `contact.scheduleNotFound` for the same
failure, so a client handling both channels should expect
both codes. |
| `directLinkedIn.scheduleHasNoSlot` | The schedule a
LinkedIn send waited for was left with no active day that
has a time range, so it never opens. Nothing went out. An
email send reads `contact.scheduleHasNoSlot` for the same
failure. |
| `directLinkedIn.contactTimeZoneMissing` | A LinkedIn
send waited for its schedule in the contact's time zone
(`useContactTimeZone` `true`), and the contact no longer
has one. Nothing went out. |
| `directLinkedIn.alreadyConnected` | A LinkedIn
connection request for later found the contact already
connected when it became due. Nothing went out. |
| `directLinkedIn.notConnected` | A LinkedIn connection
request for later found an invitation to the contact still
pending when it became due, or a LinkedIn message for
later found the contact not connected. Nothing went out. |
| `directLinkedIn.contactNotFound` | The contact of a
LinkedIn send for later was deleted, or could no longer be
found, before the send became due. Nothing went out. |
A LinkedIn send for later that is due is checked again
before it goes to the account's queue; a refusal found
then, for example a LinkedIn account no longer connected,
fails it with the `directLinkedIn.*` code the send route
answers that refusal with. Nothing went out. A failure
with no code of its own, such as an unexpected error, has
`failureCode` null and says what happened in
`failureReason`.
example: directSend.dispatchWindowMissed
failureReason:
type: string
nullable: true
description: >-
Why the send failed, as a sentence for people to read. Set
in the `failed` state only. Use `failureCode` to act on
the failure.
example: >-
The send was never attempted: its dispatch window passed
before anything picked it up.
missingVariables:
type: array
nullable: true
items:
type: string
description: >-
The variables the email's template uses that have no value
for the contact, by name without braces. Set with
`failureCode` `contact.missingVariables` only.
renderedSubject:
type: string
nullable: true
description: >-
The subject as sent, its template rendered for the
contact. Email, `sent` state only; null when the sent
message can no longer be read.
renderedBody:
type: string
nullable: true
description: >-
The body as sent, with the signature and the tracking -
its template rendered for the contact, the sending
account's signature added, and the links and open pixel of
the tracking when it is on. HTML, or text for an email
with no HTML part. Email, `sent` state only; null when the
sent message can no longer be read.
cancelledAt:
type: string
format: date-time
nullable: true
description: >-
UTC moment the send was cancelled. Set in the `cancelled`
state only.
example:
reference: email-48213
channel: email
contactId: 42
state: cancelled
sendAfter: '2026-11-20T09:00:00Z'
estimatedSendAt: null
sentAt: null
messageId: null
failureCode: null
failureReason: null
missingVariables: null
renderedSubject: null
renderedBody: null
cancelledAt: '2026-11-19T16:12:03Z'
'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: The email send was made by a teammate you may not act for.
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: The send belongs to a teammate you cannot act for.
code: directSend.notOwned
'404':
description: >-
No send has this reference, the reference is not of the form
`email-`, `linkedin-` or `linkedin-scheduled-`, or the
send belongs to another 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: Not Found
status: 404
detail: The requested resource was not found.
code: sequence.notFound
example:
title: Not Found
status: 404
detail: The send was not found.
code: directSend.notFound
'409':
description: >-
The send is past the point where it can be cancelled.
| `code` | Meaning |
|---|---|
| `directSend.alreadySent` | The send is going out or has gone out |
| `directSend.alreadySending` | The LinkedIn send for later is being
handed to the account's queue, or the account has started it, and it
has not finished |
| `directSend.alreadyFailed` | The send has failed; nothing will go
out |
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: Conflict
status: 409
detail: A resource with this name already exists.
code: sequence.duplicateName
example:
title: Conflict
status: 409
detail: The send has already gone out or is going out right now.
code: directSend.alreadySent
'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.
'503':
description: >-
The cancel could not be confirmed and the send is still waiting -
`queued` or `waitingForSchedule`, or a LinkedIn send for later still
waiting in the account's queue. Retry the cancel.
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: Service Unavailable
status: 503
detail: Background-jobs service is temporarily unavailable.
code: backgroundJob.upstreamUnavailable
example:
title: Service Unavailable
status: 503
detail: >-
The cancel could not be confirmed and the send is still
queued; retry it.
code: directSend.cancelNotConfirmed
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.