> ## Documentation Index > Fetch the complete documentation index at: https://docs.getoneprofile.ai/llms.txt > Use this file to discover all available pages before exploring further. # Answer the agent's questions on a reply > The Submit on a conversation's "Before I answer, I need to know" card (`question_card`). Give an answer to every question the card asks, each by its id; the sequence's agent then writes the reply with those answers in front of it, charged as any reply it writes, and the reply waits for a person in Needs approval. The card closes once the reply is written. When nothing usable was written it answers 409 saying so, and the card stays open. Each answer may reword its question (`question`) and says where it is kept (`scope`): `this_reply`, the default, for this reply alone, so a later Write again has it too; `saved` in the workspace's Q&A as well, which every later reply reads, so a saved question or answer naming the contact by email address or full name is refused before anything is written. A saved answer goes into the Q&A once the reply is written, signed by the person, under its question as worded: a question the Q&A has already takes the new answer, and the card's `saved_answers` offers it next time the question is asked. With `also_answer_waiting`, the agent also answers the other conversations of the sequence waiting on the same questions that the saved answers and the Q&A answer between them (the card's `others_waiting`): each is written in the background as a reply of its own, charged as any reply the agent writes, and waits for approval. One person's answers write the reply: answers sent while another person's are being written wait for them, then write nothing, and the 409 names who answered. Saving a different answer to a question the Q&A already answers changes that answer, which only a workspace admin can do; the same answer again changes nothing. A new question needs room in the Q&A. Both are checked before anything is written. ## OpenAPI ````yaml /openapi.json post /inbox/threads/{thread_id}/answers/ openapi: 3.1.0 info: contact: email: support@getoneprofile.ai name: Oneprofile Support description: >- REST API reference for Oneprofile, the GTM data layer for your CRM. Manage tables, enrichments, and integrations. Authenticate with an API key to get started. termsOfService: https://www.getoneprofile.ai/terms title: API Reference | Oneprofile version: '0.0' servers: - url: https://api.getoneprofile.ai security: [] tags: - description: >- The docked AI Assistant: its general chat about the workspace and the product, streamed as Server-Sent Events, and the one list of a person's threads across every assistant, with pin, rename, delete and the search-to-table link. name: assistant - description: >- The messages a person keeps to send the assistant again: the ones the workspace saved and the ones that ship with the product, with save, rename, edit and delete. name: assistant-prompt - description: >- Granted workspace actions: what the AI Assistant proposed or applied in a conversation, the approve and dismiss decisions on each card, the workspace's spend threshold and default grants, and the eight verbs. name: workspace-actions - description: >- The Getting started checklist: a workspace's progress through the six steps from its first people search to its first launched sequence. name: onboarding - description: Senders, connected mailboxes, tags, and the Google connect flow. name: senders - description: The workspace do-not-contact list, enforced before every send. name: suppression - description: >- The workspace's recontact rule: how long before anyone hears from us again. name: contact_cooldown - description: 'Sequence authoring: the graph, the table-backed audience, previews.' name: sequences - description: >- The outbound agent behind a sequence: the voice it writes in, its per-message prompts, what it wrote and what people told it. name: outbound-agents - description: >- The LinkedIn channel: connecting an account to a sender, its safety limits and history, and the protocol the browser extension speaks. name: linkedin - description: >- The approval queue: everything waiting on a person across every sender and channel, and the workspace's manual or automatic modes per channel. name: outreach - description: 'The unified outreach inbox: threads, replies, labels, events.' name: inbox - description: 'The AI reply layer: workspace settings, drafts, and approval.' name: inbox-ai - description: Notification rules, per-user preferences, and the Slack connection. name: notifications - description: Endpoints for seeing all available integration types. name: integration-types - description: Endpoints for creating and managing integrations. name: integrations - description: Endpoints for the generic OAuth install/claim app-listings engine. name: app-listings - description: Endpoints for creating and managing API keys. name: apikey - description: >- AI apps connected to the workspace: Claude, ChatGPT, Claude Code or any other MCP client a person signed in to Oneprofile's MCP server with. name: ai_apps - description: Endpoints for managing billing and subscription information. name: billing - description: Endpoints for creating and managing tables. name: tables - description: Endpoints for table columns, formula previews, and on-demand column runs. name: table-columns - description: Endpoints for table rows and manual cell edits. name: table-rows - description: Endpoints for observing and cancelling table recompute runs. name: table-runs - description: >- Endpoints for org-shared per-column display preferences: hidden, pinned, width, and colour tint. name: table-ui-prefs - description: >- Endpoints for the org-shared names given to the column tint palette: what this organisation calls each colour. Org-level, not per-table. name: table-column-color-labels - description: >- Endpoints for the enrichment action catalog, model list, presets, draft generation, and saved agents. name: table-enrichments - description: >- Endpoints for an agent's Preview: example rows run one at a time, and a Looks good on each. Needs work lives under agent-learnings. name: agent-training - description: >- An agent's learnings, the one-line rules it follows on every output, and the thumbs down that teaches them: give one with what was wrong, list the ones on a subject, Undo one, and price the redo it would run. name: agent-learnings - description: >- The durable audit trail of a table's enrichment actions: configured, edited, run, cancelled, and settled cost. name: table-enrichment-audit-logs - description: Endpoints for saving and applying column templates. name: table-templates - description: Server-sent change feed for a table's grid. name: table-events - description: 'Endpoints for org-shared saved table views: sort, filters, hidden columns.' name: table-views - description: >- Endpoints for PER-USER table preferences: favourites and recently opened. Unlike the rest of the table surface these are personal, so two members of one organisation legitimately see different answers. name: table-user-prefs - description: >- Endpoints for building a table from an uploaded CSV: upload and preview the inferred columns, commit the reviewed mapping, then poll the row load. name: table-imports - description: Endpoint for downloading a table's rows as CSV. name: table-export - description: >- Endpoints for the integration a table imports from: attach and preview it, promote imported fields into columns, and run the import on demand. name: table-sources - description: >- Endpoints for a table's recurring import cadence: set it, pause it, and read the next fire times. name: table-schedules - description: >- Endpoints for pushing a table's rows out to a connected integration: list writable destinations, derive their write capabilities, and map export columns. name: table-writeback - description: >- Endpoints backing a lookup column's setup: the connections whose records a column could read, and the identity fields one record type can be looked up by. name: table-integration-lookup - description: >- Endpoints for sourcing leads from the lead database: count and preview matches, land them in a table, and keep saved searches. Alongside people and company searches, leads can be sourced from buying signals (what a company or person just did), with a catalogue endpoint behind the picker that builds them. name: find-leads - description: >- Endpoints for discovering a domain's subdomains from public certificate logs and landing the results in a table. name: find-subdomains - description: Endpoints for the credit balance meter and usage reporting. name: credits - description: >- Endpoints for the workspace referral program: the shareable link, the friends who joined through it, and claiming a code after signup. name: referral - description: >- Endpoints for the affiliate program's own dashboard: enrolling and claiming a code, the summary, stats and activity feed, the commission ledger, and identity verification and payouts. name: affiliate - description: >- Endpoints for recording where a new workspace came from: the marketing page or campaign its signup link carried, sent once after signup. name: attribution - description: >- Endpoints for the design partner program's customer surface: whether this workspace is a design partner, the badges its feedback has earned, and sending and reading that feedback. name: design-partner - description: >- Endpoints for the org-level AI business context (company description, ideal customer profile, buyer personas, interest signals and social proof), plus domain-based generation and the reference documents whose summaries ride alongside those fields. name: ai-context - description: >- Endpoints for the signed-in user's Google Drive connection: starting and finishing the OAuth grant, checking or dropping it, and minting the short-lived token the Google Picker needs. name: google-drive paths: /inbox/threads/{thread_id}/answers/: post: tags: - inbox-ai summary: Answer the agent's questions on a reply description: >- The Submit on a conversation's "Before I answer, I need to know" card (`question_card`). Give an answer to every question the card asks, each by its id; the sequence's agent then writes the reply with those answers in front of it, charged as any reply it writes, and the reply waits for a person in Needs approval. The card closes once the reply is written. When nothing usable was written it answers 409 saying so, and the card stays open. Each answer may reword its question (`question`) and says where it is kept (`scope`): `this_reply`, the default, for this reply alone, so a later Write again has it too; `saved` in the workspace's Q&A as well, which every later reply reads, so a saved question or answer naming the contact by email address or full name is refused before anything is written. A saved answer goes into the Q&A once the reply is written, signed by the person, under its question as worded: a question the Q&A has already takes the new answer, and the card's `saved_answers` offers it next time the question is asked. With `also_answer_waiting`, the agent also answers the other conversations of the sequence waiting on the same questions that the saved answers and the Q&A answer between them (the card's `others_waiting`): each is written in the background as a reply of its own, charged as any reply the agent writes, and waits for approval. One person's answers write the reply: answers sent while another person's are being written wait for them, then write nothing, and the 409 names who answered. Saving a different answer to a question the Q&A already answers changes that answer, which only a workspace admin can do; the same answer again changes nothing. A new question needs room in the Q&A. Both are checked before anything is written. operationId: answer_reply_questions parameters: - in: path name: thread_id required: true schema: format: uuid title: Thread Id type: string requestBody: content: application/json: schema: $ref: '#/components/schemas/AnswerQuestionsSchema' required: true responses: '201': content: application/json: schema: $ref: '#/components/schemas/AiDraftReadSchema' description: Successful Response '401': content: application/json: schema: $ref: '#/components/schemas/UnauthorizedResponse' description: Unauthorized '402': description: >- There are not enough credits to write this reply. The card stays open. '403': description: >- An answer to be saved would change one the Q&A already holds, and only a workspace admin can. Nothing was written. '404': content: application/json: schema: $ref: '#/components/schemas/NotFoundResponse' description: Not found. '409': description: >- These questions are no longer waiting for an answer: the contact wrote again, somebody answered the reply, or its sequence writes no reply to it. Or somebody else's answers wrote the reply first, and the detail names who. Or the agent may not write it now (busy, its limit reached, the reply rejected), and the detail says why. Or the conversation's sequence has no audience table to write from. Or nothing usable was written from the answers, so there is no draft this time. The card stays open unless it was answered. '422': description: >- An answer is missing, blank or names no question on the card, or the card asks nothing (a reply only a person can answer): `questions_unanswered`. An answer to be saved names the contact: `names_contact`. The Q&A has no room for the new questions to be saved: `qa_limit_reached`. '429': description: >- The workspace has used today's AI Assistant allowance, or the AI Assistant is paused. Only a conversation outside any sequence uses the allowance. '500': content: application/json: schema: $ref: '#/components/schemas/ServerErrorResponse' description: Internal server error. '502': content: application/json: schema: $ref: '#/components/schemas/ServerErrorResponse' description: Bad gateway error. '503': content: application/json: schema: $ref: '#/components/schemas/ServerErrorResponse' description: Service unavailable. security: - APIKeyHeader: [] - HTTPBearer: [] components: schemas: AnswerQuestionsSchema: description: The answers to every question on a reply's card. properties: also_answer_waiting: default: false description: >- Also have the agent answer the other conversations of the sequence waiting on the same questions (the card's `others_waiting`), from the answers saved to the Q&A here and the Q&A's own. Each is a reply of its own, charged as any the agent writes and left for approval, written in the background. title: Also Answer Waiting type: boolean answers: description: One answer per question the card asks, each naming its question. items: $ref: '#/components/schemas/QuestionAnswerSchema' maxItems: 3 minItems: 1 title: Answers type: array message_id: description: The reply the card is on, its `question_card.message_id`. format: uuid title: Message Id type: string required: - message_id - answers title: AnswerQuestionsSchema type: object AiDraftReadSchema: properties: ask_reason: anyOf: - $ref: '#/components/schemas/AskReason' - type: 'null' description: >- Why an older release held this reply for a person when it would otherwise have sent it, for example `low_confidence`, `always_ask`, `unverified_sender`, `different_sender` or `daily_cap`. Every reply waits for a person now, so it is null on every reply written since, and on a reply a person asked for. body_text: title: Body Text type: string channel: anyOf: - $ref: '#/components/schemas/InboxChannel' - type: 'null' description: >- The channel the reply goes out on: the one the message it answers came in on, so a contact who answered a LinkedIn conversation by email is answered by email. Null on a reply written before this was recorded, which goes out on the conversation's own channel. confidence: anyOf: - $ref: '#/components/schemas/AiConfidence' - type: 'null' confidence_reason: anyOf: - type: string - type: 'null' title: Confidence Reason confidence_score: anyOf: - type: integer - type: 'null' description: >- The model's 0-100 calibration, clamped into the categorical band. Null for drafts that predate the field. Presentation only: every decision reads the categorical confidence. title: Confidence Score generated_body_text: title: Generated Body Text type: string id: format: uuid title: Id type: string learning_subject_key: anyOf: - type: string - type: 'null' description: >- What a Needs work on this reply is filed under: list its events with `GET /agent-learnings/thumbs-downs/?subject_key=`. One key for every version of the reply (Write again, a Needs work's rewrite, its Undo), so the note a Needs work left on one version is found on the next. Null on a reply no sequence's agent wrote, which has no agent to save a learning for. title: Learning Subject Key mailbox_id: anyOf: - format: uuid type: string - type: 'null' description: >- The mailbox an email reply is sent from: the one the email it answers came in to. Null on a LinkedIn reply, on one written before this was recorded, and once that mailbox is removed; each goes out from the conversation's own mailbox. title: Mailbox Id outbound_message_id: anyOf: - format: uuid type: string - type: 'null' description: >- The agent's message this reply came from, when a sequence's agent wrote it. Ratings and the send are recorded against that message too, as a record that saves no learning: only Needs work on the draft does. Null on a reply written in the default voice for a conversation outside any sequence. title: Outbound Message Id rating: anyOf: - $ref: '#/components/schemas/DraftRating' - type: 'null' description: The human verdict on this draft, when one was given. send_after: anyOf: - format: date-time type: string - type: 'null' description: >- When an older release would have sent a `scheduled` reply; nothing sends it now. Kept on a reply that release sent. Null on a reply that was never scheduled, and on one handed back to a person, edited or approved. title: Send After send_outcome: anyOf: - $ref: '#/components/schemas/DraftSendOutcome' - type: 'null' description: >- How the words a person sent stand to what the AI wrote, decided as they sent it. `as_written`: the AI's words, unchanged. `edited`: the person changed them and kept what they say. `replaced`: the person sent a reply of their own in its place. Null until a person sends it, on a reply an older release sent without one, and on one sent before this was recorded. sent_by_kind: anyOf: - $ref: '#/components/schemas/MessageSentByKind' - type: 'null' description: >- Who sent the reply: `person` when someone approved it, `system` on a reply an older release sent without one. Null until it is sent. source: $ref: '#/components/schemas/AiDraftSource' status: $ref: '#/components/schemas/AiDraftStatus' description: >- Where this reply stands. `pending_approval`: waiting for a person to approve, edit or discard it. `scheduled`: a reply an older release scheduled, which nothing sends now; it waits for a person exactly as `pending_approval` does, and is approved, edited or discarded the same way. `sending`: it is leaving now and can no longer be changed. `send_unknown`: it was sent, but the mailbox has not confirmed it yet; it settles on its own as `sent` or `send_failed`. `send_failed`: it did not go; write a fresh reply. `sent`: it went out. `discarded`: a person rejected it or asked for a new version. `stale`: the contact wrote again before anyone answered it. steer_text: anyOf: - type: string - type: 'null' title: Steer Text subject: anyOf: - type: string - type: 'null' title: Subject thread_id: format: uuid title: Thread Id type: string required: - id - thread_id - status - source - steer_text - subject - body_text - generated_body_text - confidence - confidence_reason title: AiDraftReadSchema type: object UnauthorizedResponse: properties: detail: description: The detail of why the request is unauthorized. title: Detail type: string required: - detail title: UnauthorizedResponse type: object NotFoundResponse: properties: detail: description: The detail of why the resource was not found. title: Detail type: string required: - detail title: NotFoundResponse type: object ServerErrorResponse: properties: detail: description: The detail of why the server returned an error. title: Detail type: string required: - detail title: ServerErrorResponse type: object QuestionAnswerSchema: description: A person's answer to one of the agent's questions on a reply. properties: answer: description: The answer, as the reply may state it. maxLength: 2000 minLength: 1 title: Answer type: string question: anyOf: - maxLength: 300 minLength: 1 type: string - type: 'null' description: >- The question as the person reworded it; null keeps the agent's words. title: Question question_id: description: The question's id, from the conversation's `question_card`. maxLength: 16 minLength: 1 title: Question Id type: string scope: $ref: '#/components/schemas/AnswerScope' default: this_reply description: >- `this_reply` keeps the answer for this reply alone, so every later writing of it has it. `saved` also keeps it in the workspace's Q&A, which every later reply reads, so its question and answer may not name the contact. required: - question_id - answer title: QuestionAnswerSchema type: object AskReason: description: >- Why a message that could have sent unattended was put in front of a person. One vocabulary for every gate between an agent writing a message and the message leaving: what the agent itself said about the draft (``LOW_CONFIDENCE``, ``FINDINGS``, ``INSUFFICIENT_DATA``, ``POLICY``), what the sender or the cadence asked for (``ALWAYS_ASK``, ``SEQUENCE_MANUAL``, ``STEP_REQUIRES_APPROVAL``), what the pacing rules refused (``DAILY_CAP``, ``CONSECUTIVE_CAP``, ``THREAD_CAP``, ``HOURLY_CAP``, ``ORG_DAILY_CAP``), what the mailbox or the thread made unsafe (``UNVERIFIED_SENDER``, ``DIFFERENT_SENDER``, ``LABEL``, ``QUESTION``, ``STALE_INBOUND``, ``SEQUENCE_GONE``), and what the counterparty turned out to be (``BOT_QUESTION``, ``AUTOMATED_COUNTERPARTY``, ``AUTHENTICATION``, ``LANGUAGE``, ``LINKEDIN_ONLY``). ``KILL_SWITCH`` is the platform switch that stops unattended sending outright, and ``SEND_INTERRUPTED`` an unattended reply whose send never got as far as a provider. ``SENDER_SWITCHED_TO_MANUAL`` is a LinkedIn step queued unasked that went back to a person because its sender switched to manual before it ran. Stored on the task so the queue can say why each row is there, and so "why did nothing send" is answerable by counting rows rather than by reading logs. enum: - low_confidence - findings - insufficient_data - policy - always_ask - sequence_manual - step_requires_approval - daily_cap - unverified_sender - suppressed - different_sender - label - question - consecutive_cap - thread_cap - hourly_cap - org_daily_cap - stale_inbound - sequence_gone - bot_question - automated_counterparty - kill_switch - authentication - language - linkedin_only - send_interrupted - sender_switched_to_manual title: AskReason type: string InboxChannel: description: >- Which surface a conversation happens on. Threads are contact-scoped, not channel-scoped, so this says how a thread is REACHED rather than partitioning the inbox: a reply arrives, is classified and stops the cadence identically either way, and only the send path differs. enum: - email - linkedin title: InboxChannel type: string AiConfidence: description: >- How sure the model is. Shown on the card; no band sends without a person. enum: - high - medium - low title: AiConfidence type: string DraftRating: description: |- The human verdict on a drafted reply. Two values, not five stars: a triaging human will click a thumb, not deliberate over a scale, and "good or bad" is all a feedback loop needs. enum: - good - bad title: DraftRating type: string DraftSendOutcome: description: >- How the words a person sent stand to the reply the AI wrote. ``AS_WRITTEN``: the AI's words, unchanged. ``EDITED``: the person changed them and kept what they say, which is the one outcome that teaches the agent. ``REPLACED``: the person sent a reply of their own in its place, which credits the agent with nothing. Decided before the send, never by the send. enum: - as_written - edited - replaced title: DraftSendOutcome type: string MessageSentByKind: description: >- Who composed an outbound message: a person, or the product itself. Only meaningful outbound, and NULL on anything inbound. The distinction exists because an agent-written reply has to stay attributable after the fact: "did a human send this" is the first question asked of any send that turns out to have been wrong, and a column is the only place that answer survives. enum: - person - system title: MessageSentByKind type: string AiDraftSource: enum: - auto_drafted - on_demand title: AiDraftSource type: string AiDraftStatus: description: >- Where one drafted reply stands. STALE is its own terminal state rather than a flavour of DISCARDED: "the prospect wrote again before anyone answered" and "a human said no" are different facts, and only the second one says anything about draft quality. The send states past SCHEDULED exist for the same reason SEND_UNKNOWN does: once a draft can leave without a person watching, "we do not know" has to be a state of its own. Collapsing it into SEND_FAILED would have a retry send the same reply twice; collapsing it into SENT would lose a reply silently. enum: - pending_approval - sent - discarded - stale - scheduled - sending - send_unknown - send_failed title: AiDraftStatus type: string AnswerScope: description: >- Where a person's answer to one of the agent's questions is kept (G3, 2026-10-19). ``THIS_REPLY``: for the reply the question is on alone, kept on its assessment so every later writing of that reply has it. ``SAVED``: in the workspace's Q&A too, which every later reply reads; a saved question names nothing of the contact. enum: - this_reply - saved title: AnswerScope type: string securitySchemes: APIKeyHeader: in: header name: X-API-Key type: apiKey HTTPBearer: scheme: bearer type: http ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.