Settings API
Everything that shows up under the dashboard’s Settings tab — the organization profile, user preferences, in-app notifications, team & invites, API keys, sender IDs, single sign-on (SAML & SCIM), HIPAA controls, privacy, compliance policies, and keyword / opt-out rules. Base path:/api/v1/settings
Authentication: Session JWT (most operations are admin/owner-gated).
Using the SDKs
client.request() escape hatch above. See the Python SDK.
Returns the typed ApiResponse envelope. See the SDK index at SDK quickstart.
Organization
User preferences
PUT /api/v1/settings/preferences is a partial update — send only what changes:
Notifications
DELETE /api/v1/settings/notifications clears the org’s notification list and returns 204 No Content.
Team
Invite a member by assigning one of the assignable roles (
admin, supervisor, developer, viewer, billing):
DELETE /api/v1/settings/team/{userId} removes a member, and DELETE/POST .../resend on /team/invites/{email} cancels or re-sends a pending invite; all three return 204 No Content.
The invited user accepts the invite with the token from the invitation email (presented on the accept-invite page):
API keys
POST /api/v1/settings/api-keys returns the plaintext key once — stored with a _warning because it is never readable again. expiresIn accepts never, 30d, 90d, or 1y; allowed_ips accepts bare IPs or CIDRs (empty = unrestricted). mode: "test" activates sandbox mode (no delivery, no charges).
1–168 hours) while you swap it everywhere; mode: "immediate" revokes at once:
POST /api/v1/settings/api-keys/{id}/cancel-revoke.
Sender IDs
Many countries require sender ID pre-registration before alpha-numeric sender IDs can be used. The full list of operations (including delete + status checks) is in the auto-generated reference below.
Register an alphanumeric sender ID for SMS (≤ 11 characters on that channel) — it starts
pending and becomes sendable when the destination registry approves it:
Single sign-on (SAML & SCIM)
Configure enterprise SSO and directory provisioning for the org. These endpoints manage the configuration; the login and provisioning flows your identity provider calls live on the public/auth/saml/* and /scim/v2/* paths documented under Authentication.
The SSO URL and metadata URL are validated to block requests to internal or private addresses. When you configure SAML for the first time,
PATCH /api/v1/settings/saml requires an x509Cert; once one is stored, omit the field to change other settings without re-uploading it.
x509Cert (the IdP’s PEM signing certificate). The response echoes the saved configuration with cert_fingerprint_sha256 — never the raw certificate.
HIPAA controls
Manage covered-entity mode, the Business Associate Agreement (BAA) record, and the PHI access log. Reads require an admin; enabling, disabling, and BAA changes are owner only.
Disabling HIPAA mode is protected.
PUT /api/v1/settings/hipaa with enabled: false returns 401 REAUTH_REQUIRED unless you first call POST /api/v1/settings/hipaa/reauth-challenge and replay the returned token in an X-Reauth-Challenge header within 5 minutes. Enabling HIPAA and retention-only updates do not require re-auth.
See HIPAA compliance for the full covered-entity guide.
Enable covered-entity mode and set the data-retention window; reads come back with your BAA state so you can confirm what applies before you record a signed BAA:
Privacy
Control PII redaction and transcript retention for the org. Reads are available to any member; updates are owner/admin only.
The body of
PUT /api/v1/settings/privacy accepts:
pii_redaction_enabled(boolean) — mask phone numbers and email addresses on screen for viewer-tier operators. Display only; dial targets and outbound payloads still carry raw E.164.pii_redaction_in_transcripts(boolean) — scrub PII from agent conversation turns at write time. Applies to new turns only; existing turns are not back-redacted.transcript_retention_days(integer 1–3650, ornullfor no deletion) — the nightly retention job deletes agent conversations and messages older than this window.
Compliance
Per-org compliance and outbound-safety policies enforced on the send path. Each resource exposes a read (available to any member) and a write (owner only).
The country allowlist is tenant-scoped — it constrains only your own org’s outbound traffic, never another tenant’s.
The work below is self-serve tenant configuration; compliance topics document tenant-owned controls only. Pair a read (
GET) with a write (PATCH or PUT, owner/admin) so callers hold the current value before updating it.
Policy scan mode — set the pre-send policy scanner:
countries array replaces the previous list; sending an empty array with allow_all: false blocks every destination until reconfigured:
folder or suppress):
GET / PATCH on unknown-marketing-policy and consent-default-policy, and the consent-audit posture read (GET /api/v1/settings/compliance/consent-audit — no write counterpart, so it is read-only), all use the same envelope. For every compliance resource, a plain GET returns the saved value in the same envelope shape.
Keyword & opt-out rules
Automated inbound-keyword handling and STOP/START opt-out management. Keyword-rule writes require the developer role or higher; opt-out-rule writes require an admin. Both list endpoints are paginated.Keyword rules
A rule matches an inbound
keyword on a channel (sms, whatsapp, rcs, viber, email) with a match_type of exact, contains, starts_with, or regex, then runs an action: reply with response_text, forward to an agent_id, trigger a flow_id, or opt the contact out / back in.
Opt-out rules
Opt-out rules are keyword rules whose
action is opt-out or opt-in (for example STOP and START). Set auto_reply_text to confirm the change back to the contact. See Opt-outs & suppression for how suppression is enforced at send time.
Worked sequences
The walk-through below covers the keyword-rule and opt-out-rule surfaces end to end in the order an integration typically drives them: create, list, update, then delete. Keyword-rule bodies are snake_case; responses return the stored rule in camelCase. Step 1 — create a keyword ruleGET /api/v1/settings/keyword-rules returns all rules; GET /api/v1/settings/opt-out-rules narrows to the opt-out/opt-in subset. Both are cursor-paginated — follow meta.pagination.cursor while has_more is true:
PUT /api/v1/settings/keyword-rules/{id} is a partial update — send only the fields to change; it returns the updated rule id (fetch the full record with GET if you need it):
PUT /api/v1/settings/opt-out-rules updates up to 100 rules in one call — the dashboard bulk-edit save. Each entry names the rule id plus the fields to change (keyword, channel, action, auto_reply_text, or active to toggle without deleting):
DELETE /api/v1/settings/keyword-rules/{id} and DELETE /api/v1/settings/opt-out-rules/{id} both return the deleted id:
See also
- Authentication — API key types and rotation patterns
- Compliance — security & access logging requirements