> ## Documentation Index > Fetch the complete documentation index at: https://docs.flowyte.com/llms.txt > Use this file to discover all available pages before exploring further. # Record a contact's express SMS consent captured outside a text > Record that a person gave your business EXPRESS consent to receive text messages somewhere other than a text — a booking or web form, at the point of sale, verbally, on paper, or in an import from your own system — so that sendSMSMessage (POST /sms/messages) can text them. WHY IT EXISTS. Texting a person first requires a recorded consent basis. The platform records one automatically in two cases: `conversational` when the person texts one of your numbers first, and `express` when they agree during a call or chat with your agent. Consent your business collected anywhere else is invisible to the platform until you record it here. WHAT IT WRITES. One append-only consent-ledger record (the evidence: when, how, the disclosure the person agreed to, and an optional link to your own proof), the contact's consent tier set to `express` (visible on listSMSContacts and in the consent export), and a compliance-trail entry naming the API key or user that attested it. The ledger stores the capture method as `api:` (e.g. `api:web_form`), so the record shows it was attested through the API — that is the `consentSource` listSMSContacts and the export report; this response's `source` is the bare method you sent. Recording consent never lowers a contact's tier and is safe to repeat — each call appends one more ledger record. `basis` must be `express`. `conversational` cannot be asserted: it is stamped by the platform only when the person actually texts you. YOU ARE ATTESTING. The record states that your business holds this consent, and it appears in the consent export (exportSMSContacts) as part of your proof. Keep the underlying evidence yourself — `evidenceUrl` and `reference` should point at it. OPT-OUTS STILL WIN. If the person replied STOP, recording consent does NOT re-enable them — the response is still 200 with `optedOut: true`, and sends stay refused 409 `sms_suppressed` until they text START or you re-enable them with DELETE /sms/suppressions/{e164} (which requires fresh, documented consent). ## OpenAPI ````yaml /openapi.yaml put /sms/contacts/{e164}/consent openapi: 3.1.0 info: title: Flowyte V2 Control-Plane REST API version: 1.0.0 description: >- The single REST API for the Flowyte platform (base path `/api/v1`). Authenticate every request with a secret API key — `Authorization: Bearer flowyte_sk_…` — and each operation lists the scope the key must hold. Successful responses use the `ApiResponse` envelope; list responses use cursor-based `PaginatedResponse`. Errors are RFC 9457 problem+json. Streaming endpoints return Server-Sent Events (`event:\ndata:\n\n`, terminating with `event: done`). contact: name: Flowyte Platform license: name: Proprietary servers: - url: /api/v1 description: Flowyte control-plane (versioned URI; additive in v1). security: - apiKey: [] tags: - name: Agents description: The single user-facing entity. - name: Support description: In-app "Get help" form → support inbox email. - name: Skills description: > Agent capabilities / tools. A skill is ONE atomic action — typically a single API call the agent makes in one step (look up an order, create a record, send a message, transfer the call). Use a skill when the task is a single step. When a task needs several details gathered across turns BEFORE acting, build a Playbook (which gathers the inputs and then calls skills) — see the Playbooks tag. - name: Integrations description: Native OAuth integrations. - name: Knowledge description: RAG knowledge sources & preview. - name: Playbooks description: > Multi-turn conversation scripts — a node graph (gather → confirm → branch) the agent follows to collect several inputs IN ORDER across turns before acting. Build a playbook when a single skill call isn't enough because the agent must gather MANY details first, or run a SEQUENCE of skills, before it can finish (e.g. take a full service request: gather the problem, address, and time, confirm, THEN file it; qualify a lead; a multi-step intake). A playbook does NOT call an integration itself — it owns the conversation and holds the state across turns; the actual action is performed by the SKILL(s) it gathers the inputs for. So a playbook ORCHESTRATES skills. Rule of thumb — one API call → a Skill; "gather N things in order, then submit" → a Playbook that drives the conversation and calls the skill(s) at the end. - name: Variables description: > The agent-wide interaction-variable registry — DERIVED at read time from the agent's playbooks and skills (collect slots, skill output bindings, {var} placeholders) and merged with a thin annotation overlay (notes, declared type hints, manual declarations). Read-only observation, NEVER a gate: it never validates a reference and never affects authoring, publish, or runtime behaviour. - name: Guardrails description: Deterministic guardrail policies & caller verification. - name: Numbers description: Phone numbers / DIDs. - name: SMS description: > SMS Hub — A2P 10DLC self-serve registration (brand + campaign), the free AI compliance review, per-number SMS enablement, the consent/opt-out surface (suppressions, contacts, recorded consent, TCPA proof export), and sending a text from the API. Sending numbers are US-only; a number must be SMS-enabled and the org's 10DLC registration active before it can send. - name: Test description: Test, simulate, talk-token, probe. - name: Observe description: Post-call analytics, conversations, receipts, transcripts. - name: Billing description: Plans, wallet, usage, fixed phrases. - name: Voices description: Voice catalog. - name: ApiKeys description: Developer / API keys. - name: Webhooks description: Webhook endpoints & deliveries. - name: Records description: > Caller Context Store — pre-synced external records the agent greets a caller from, plus the learned object-type field registry. Fed by the Zapier app's Create/Update Record action and directly by this REST API; read at call time by the context_lookup skill (a sub-100ms local lookup, no Zapier round-trip). - name: AuditLogs description: API/key activity logs. - name: Chat description: Chat channel — sessions, messages, OpenAI-compatible, widget. - name: PublishableKeys description: Browser-safe, one-agent publishable keys. - name: Widget description: Embed widget config + snippet. - name: Uploads description: Multipart file uploads backing file_id params - name: Meta description: Platform metadata (language/SKU/tier capabilities). - name: Outbound description: > Outbound voice — contact lists (import + scrub) and campaigns (create, launch, pause/resume/cancel). Launch schedules one call attempt per valid contact; a background worker dials them. This release dials informational campaigns only. - name: Team description: > Team Members — the general "invite a teammate" surface (roster, the platform invitations, role changes/removals, and the domain-discovery join-request inbox). Distinct from the Flowyte Phone SEAT surface: a team invite mints NO softphone seat. Reads → team:read; mutations → team:write (owner/admin; staff is role-gated out). Owner-only guards protect owner grants/edits and the org's last owner; no self-role-change or self-removal. - name: Onboarding description: > Pre-org domain discovery — the signup-flow seam a just-signed-in user hits BEFORE they have a workspace, to learn "your coworkers may already be here" and ask to join. Engine-root, authenticated by a the platform session JWT that may have no active org; tenancy is derived SERVER-SIDE from the caller's verified email (anti-enumeration), never from input. - name: OAuth2 description: > Flowyte's minimal OAuth2 authorization server. The Flowyte Zapier app is the first registered client. The authorization-code grant (confidential client, optional PKCE) issues org-scoped SERVICE tokens (flowyte_oat_…) that ride the SAME scope matrix as an sk key. The public authorize/token/revoke endpoints are served at the ORIGIN ROOT (NOT under /api/v1 — see each path's `servers` override); consent + disconnect are /api/v1. paths: /sms/contacts/{e164}/consent: parameters: - name: e164 in: path required: true description: The contact's number in E.164 format (e.g. +14155551234). example: '+14155551234' schema: type: string put: tags: - SMS summary: Record a contact's express SMS consent captured outside a text description: > Record that a person gave your business EXPRESS consent to receive text messages somewhere other than a text — a booking or web form, at the point of sale, verbally, on paper, or in an import from your own system — so that sendSMSMessage (POST /sms/messages) can text them. WHY IT EXISTS. Texting a person first requires a recorded consent basis. The platform records one automatically in two cases: `conversational` when the person texts one of your numbers first, and `express` when they agree during a call or chat with your agent. Consent your business collected anywhere else is invisible to the platform until you record it here. WHAT IT WRITES. One append-only consent-ledger record (the evidence: when, how, the disclosure the person agreed to, and an optional link to your own proof), the contact's consent tier set to `express` (visible on listSMSContacts and in the consent export), and a compliance-trail entry naming the API key or user that attested it. The ledger stores the capture method as `api:` (e.g. `api:web_form`), so the record shows it was attested through the API — that is the `consentSource` listSMSContacts and the export report; this response's `source` is the bare method you sent. Recording consent never lowers a contact's tier and is safe to repeat — each call appends one more ledger record. `basis` must be `express`. `conversational` cannot be asserted: it is stamped by the platform only when the person actually texts you. YOU ARE ATTESTING. The record states that your business holds this consent, and it appears in the consent export (exportSMSContacts) as part of your proof. Keep the underlying evidence yourself — `evidenceUrl` and `reference` should point at it. OPT-OUTS STILL WIN. If the person replied STOP, recording consent does NOT re-enable them — the response is still 200 with `optedOut: true`, and sends stay refused 409 `sms_suppressed` until they text START or you re-enable them with DELETE /sms/suppressions/{e164} (which requires fresh, documented consent). operationId: recordSMSContactConsent requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/RecordSMSContactConsentRequest' example: basis: express source: web_form capturedAt: '2026-09-20T14:03:00.000Z' disclosureText: >- I agree to receive appointment texts from Kiwi Cleaning. Msg & data rates may apply. Reply STOP to opt out. evidenceUrl: https://kiwicleaning.example/booking/8812 reference: booking_8812 responses: '200': description: >- Consent recorded; the contact's tier is now `express`. Also 200 when the contact is opted out — check `optedOut`. content: application/json: schema: $ref: '#/components/schemas/ApiResponse_SMSContactConsent' example: success: true data: phoneNumber: '+14155551234' consent: express consentRecordId: 3d6f9a1c-2b4e-4f80-9c1d-5e6f7a8b9c0d source: web_form capturedAt: '2026-09-20T14:03:00.000Z' recordedAt: '2026-09-24T16:12:45.000Z' optedOut: false '400': $ref: '#/components/responses/ValidationError' description: >- `validation_error` — `basis` is missing or not `express`; `source` is missing or not one of the allowed values; `capturedAt` is not RFC 3339, is in the future, or is more than four years old; `disclosureText` exceeds 2,000 characters; `evidenceUrl` is not an `https://` URL or exceeds 512 characters; or `reference` exceeds 200 characters. '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/Forbidden' description: >- Refused — the API key lacks the `sms:write` scope (`insufficient_scope`). '422': $ref: '#/components/responses/Unprocessable' description: '`invalid_phone` — the path number is not a valid E.164 number.' security: - apiKey: - sms:write components: schemas: RecordSMSContactConsentRequest: type: object required: - basis - source description: >- Evidence of express consent your business captured outside a text message. properties: basis: type: string enum: - express description: >- The consent basis being recorded. Only `express` can be asserted — `conversational` is recorded by the platform when the person texts you first. source: type: string enum: - web_form - point_of_sale - verbal - paper - import - other description: Where the person gave consent. capturedAt: type: string format: date-time description: >- When the person gave consent (RFC 3339). Defaults to now. Must not be in the future or more than four years ago. disclosureText: type: string maxLength: 2000 description: >- The exact wording the person agreed to. Strongly recommended — it is the core of your consent proof. When omitted, the record says exactly: "Express consent to receive text messages from the business, attested by the workspace through the API (capture method: ). No verbatim disclosure wording was supplied." evidenceUrl: type: string format: uri maxLength: 512 description: >- An `https://` link to your own record of the consent (the signed form, the booking, the recording). reference: type: string maxLength: 200 description: >- Your own identifier for the consent event (a booking, order or form-submission id). ApiResponse_SMSContactConsent: allOf: - $ref: '#/components/schemas/ApiResponseBase' - type: object required: - data properties: data: $ref: '#/components/schemas/SMSContactConsent' ApiResponseBase: type: object required: - success properties: success: type: boolean message: type: string errors: type: array items: type: object required: - field - message properties: field: type: string message: type: string SMSContactConsent: type: object required: - phoneNumber - consent - consentRecordId - source - capturedAt - recordedAt - optedOut description: The result of recording a contact's express consent. properties: phoneNumber: type: string description: The contact's number (E.164). consent: type: string enum: - express description: The contact's consent tier after the write — always `express`. consentRecordId: type: string description: The id of the consent-ledger record this call appended. source: type: string enum: - web_form - point_of_sale - verbal - paper - import - other description: Where the person gave consent, as recorded. capturedAt: type: string format: date-time description: When the person gave consent, as recorded. recordedAt: type: string format: date-time description: When this record was written. optedOut: type: boolean description: >- True if the number is on the opt-out (suppression) list. Recording consent does not lift an opt-out — sends stay refused until the person texts START or the number is re-enabled via DELETE /sms/suppressions/{e164}. ProblemDetails: description: RFC 9457 problem+json. type: object properties: type: type: string format: uri default: about:blank title: type: string status: type: integer detail: type: string instance: type: string code: type: string errors: type: array items: type: object properties: field: type: string message: type: string ApiResponse_Void: allOf: - $ref: '#/components/schemas/ApiResponseBase' - type: object properties: data: type: - object - 'null' responses: ValidationError: description: Validation failure (errors[] populated on the envelope). content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' application/json: schema: $ref: '#/components/schemas/ApiResponse_Void' Unauthorized: description: Missing or invalid API key. headers: WWW-Authenticate: schema: type: string content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' Forbidden: description: Org mismatch / RLS / insufficient scope / origin not allowed. content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' Unprocessable: description: Semantically invalid (e.g. language not in SKU's STT set). content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' securitySchemes: apiKey: type: oauth2 description: > Flowyte secret API key (`Authorization: Bearer flowyte_sk_live_…`). Scope-gated; is scoped to your organization — a key can never reach another tenant. The listed scopes in each operation's `apiKey` requirement are the scopes that key must hold. The `tokenUrl` is nominal: keys are minted in the dashboard. flows: clientCredentials: tokenUrl: /api/v1/api-keys scopes: agents:read: Read agents. agents:write: Create/update/delete agents, publish, rollback. knowledge:read: Read knowledge sources & preview. knowledge:write: Add/remove knowledge sources, uploads. skills:read: Read skills & skill-types. skills:write: Create/update/delete skills. playbooks:read: Read playbooks & graphs. playbooks:write: Create/update/delete playbooks & graphs. guardrails:read: Read guardrail policies & caller-verification. guardrails:write: Update guardrail policies & caller-verification. numbers:read: Read phone numbers / search availability. numbers:write: Purchase / assign / release numbers. sms:read: Read the org's SMS (10DLC) registration status and numbers. sms:write: >- Save/submit the 10DLC registration, toggle numbers for SMS, and record or revoke a contact's SMS consent. sms:send: >- Send outbound text messages from the org's SMS-enabled numbers (consent, opt-out and quiet hours are enforced server-side). outbound:read: Read outbound contact lists and campaigns. outbound:write: >- Create/import contact lists, create/launch/pause/resume/cancel outbound campaigns, and enqueue single outbound calls. integrations:read: Read connected native integrations (status only — never tokens). integrations:write: Discover schemas, set data scoping, and disconnect a connection. integrations:connect: >- Connect a data source (submit credentials / begin OAuth) — a SEPARATE, higher-privilege scope because connecting INGESTS credentials and opens a new egress path; a discover/scope/author key need not carry it. records:read: >- Read the pre-synced Caller Context Store records and object-type field registry. records:write: >- Upsert / delete / bulk-import / purge caller-context records and edit type metadata. calls:read: Read conversations, receipts, transcripts, analytics. analytics:read: >- Read the Observe history list, per-agent analytics (the answer-rate summary), the raw knowledge-gap list, and the metric catalog + per-metric queries + metric drill-downs. analytics:write: >- Curate knowledge gaps (dismiss / mark in-progress). [M4 — reserved] dashboards:read: List and read saved Observe reporting dashboards. dashboards:write: >- Create, update (full-document replace), and delete Observe reporting dashboards. reports:read: List and read Observe scheduled reports (report schedules). reports:write: >- Create, update, and delete Observe scheduled reports (a delete stops a recurring digest). billing:read: Read plans, wallet, usage. audit:read: Read API/key activity logs. webhooks:write: Manage webhook endpoints. keys:write: Manage secret API keys. chat:read: Read chat sessions & messages. chat:write: Create chat sessions & send messages (server-side). widgets:read: Read widget config & embed snippet. widgets:write: Update widget config. pubkeys:read: Read publishable keys. pubkeys:write: Manage publishable keys. phone:read: >- Read Flowyte Phone config — settings, ring targets/queues + rosters, contacts, block-list, own presence. phone:write: >- Update Flowyte Phone config — settings, ring targets/queues + members, contacts, block-list. presence:write: Set your own softphone presence (available/away/dnd/…). team:read: Read the team — softphone seats and the team presence roster. team:write: >- Manage softphone seats — invite, update, and deactivate team members. escalation_destinations:read: Read external-agent (AI Harness) escalation destinations. escalation_destinations:write: >- Create, update, delete, and rotate the signing secret of escalation destinations. escalation_policies:read: Read an agent's escalation routing policy. [ — reserved] escalation_policies:write: Update an agent's escalation routing policy. [ — reserved] escalations:read: >- Read escalation sessions and their message history (connector). [ — reserved] escalations:claim: >- Claim an escalation session and extend its lease (connector). [ — reserved] escalations:respond: >- Post messages into a claimed escalation session (connector). [ — reserved] escalations:resolve: >- Resolve, return, or request human takeover of an escalation (connector). [ — reserved] escalations:initiate: >- Start a NEW outbound SMS conversation with a customer (connector). Deliberately separate from escalations:respond — the other scopes work a conversation the platform handed over; this one texts a person who never contacted you on that thread. Also requires the org to be enabled for harness-initiated conversations. ````