{"openapi":"3.0.3","info":{"title":"Elvo Public API","version":"1.4.0","description":"Welcome to the Elvo REST API — the programmatic way to work with conversations, comments, contacts, and the workspace itself: members and invitations, teams, channels, tags, canned responses, automation rules, the AI knowledge base, performance reports, and your own out-of-office status. Elvo is AI-first: everything an admin can do in the dashboard is meant to be doable from here, so an agent or a pipeline can run the workspace without opening the UI.\n\n## Getting started\n\n### 1. Create an API token\n\nTokens are created inside Elvo under **Settings → API & agents** (Icelandic: **API og gervigreind**).\n\n➡️ **[Open the token settings](/?settings=open&tab=api)** (must be signed in as an admin)\n\nBuilding an AI agent? Read [llms.txt](https://elvo.is/llms.txt) first: it starts with a short agent quickstart. The human guide is [Use your own AI agent with Elvo](https://elvo.is/help/ai-agents).\n\nYou'll be prompted for a **name**, a **scope**, and an optional **expiry**:\n\n- **Read** (recommended default) — token can only make `GET` and `HEAD` requests.\n- **Write** — token can also `POST`, `PATCH`, and `DELETE` to create and update resources.\n\nThe plaintext token is shown **once**. Copy it immediately and store it in your secrets manager — Elvo never displays it again.\n\n### 2. Authenticate\n\nSend the token in the `Authorization` header on every request:\n\n```\nAuthorization: Bearer elvo_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n```\n\n### 3. Make a request\n\nBase URL: `https://elvo.is/api/public/v1`\n\n```bash\ncurl https://elvo.is/api/public/v1/conversations \\\n -H \"Authorization: Bearer elvo_...\"\n```\n\n## Conventions\n\n- **Envelope**: single resources return `{ \"data\": ... }`, lists return `{ \"data\": [...], \"pagination\": { \"next_cursor\", \"has_more\" } }`.\n- **Pagination**: cursor-based. Pass `?cursor=&limit=25` (max 100).\n- **IDs**: every id (conversation, comment, contact, user, team, tag) is a UUID. `conversation_number` is the short number people see in the dashboard, not an id.\n- **Sort order**: list endpoints return newest first (`created_at` descending) unless the endpoint says otherwise.\n- **Timestamps**: ISO 8601 in UTC.\n- **Field casing**: `snake_case` everywhere — both query parameters and JSON fields.\n- **Compatibility**: new response fields and new enum values may appear in any release without a version bump — ignore fields you don't know. Removing or renaming a field, or changing its type, only happens in a new API version.\n- **Errors**: `{ \"error\": { \"type\", \"message\", \"details\" } }` with types `authentication_error`, `authorization_error`, `validation_error`, `not_found`, `method_not_allowed` (HTTP 405, with an `Allow` header), `rate_limit_exceeded`, `conflict`, `plan_limit` (HTTP 402 — a plan cap on seats, teams, rules or canned responses; `details` carries `{ feature, limit, current, plan }`), `internal_error`.\n- **Permissions**: a token acts as the member who created it. Routes the dashboard reserves for organization admins (members, invitations, teams, knowledge) require a token created by an admin — otherwise `403 authorization_error`. If that member is demoted or deactivated, their tokens follow within a minute.\n- **Unknown query parameters**: send only the parameters an operation documents. Unknown parameters are rejected with `400 validation_error`, so a typo does not silently return unfiltered data.\n- **Rate limits**: 200 reads/minute and 60 writes/minute per token (sliding window; `GET` routes count as reads, every other method as writes). Responses carry `X-RateLimit-Limit`, `X-RateLimit-Remaining` and `X-RateLimit-Reset` (an ISO 8601 timestamp, not unix seconds). A `429` also carries `Retry-After` (seconds) and `error.details.retry_after_seconds`. Error responses other than 429 may omit the `X-RateLimit-*` headers.\n\n## Conversation statuses\n\n| Status | Meaning |\n|---|---|\n| `open` | Needs a reply or action from your team. The working queue. |\n| `pending` | Your team replied and is waiting for the customer. |\n| `resolved` | Done. There is no `closed` status: to close a conversation, set `resolved`. |\n| `ignored` | Spam or noise (the dashboard's spam folder). |\n| `deleted` | In the trash. |\n\nA new customer message on a `pending`, `resolved`, `ignored` or `deleted` conversation normally moves it back to `open`. Sending a reply on a `resolved`, `ignored` or `deleted` conversation reopens it unless you pass a `status`.\n\nTwo flags sit beside the status and do not change it:\n\n- **Archived** (`archived_at` set): filed out of every inbox view. `GET /conversations` includes archived conversations by default (`archived=all`); pass `archived=hide` to match what the inbox shows.\n- **Snoozed** (`snooze_until` in the future): hidden until that time. `GET /conversations` hides snoozed conversations by default (`snoozed=hide`); pass `snoozed=all` or `snoozed=only` to see them.\n\n## Recipes\n\n**Triage a backlog**\n1. `GET /conversations?status=open&assigned_to_id=`\n2. For each: read latest comments via `GET /conversations/{id}/comments?include_internal=true`\n3. Reply or close: `POST /conversations/{id}/comments` with `{ \"content\": \"...\", \"status\": \"resolved\" }`\n\n**Reply with internal note**\n```bash\ncurl -X POST https://elvo.is/api/public/v1/conversations//comments \\\n -H \"Authorization: Bearer elvo_...\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"content\":\"Asked accounting to confirm refund eligibility.\",\"is_internal\":true}'\n```\n\n**Label and reassign**\n```bash\ncurl -X PATCH https://elvo.is/api/public/v1/conversations/ \\\n -H \"Authorization: Bearer elvo_...\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"tags\":[\"billing\",\"vip\"],\"assigned_to_id\":\"\"}'\n```\n\n## Managing the workspace\n\nThe same admin surface as **Settings** in the dashboard, so provisioning and configuration can live in your own systems.\n\n**Onboard a new agent** (admin-owned write token)\n1. `POST /invitations` with `{ \"email\", \"name\", \"role\": \"agent\", \"team_ids\": [\"\"] }` — Elvo emails the invitation; the member appears in `GET /users` once they accept, already in those teams.\n2. Later: `POST /teams/{id}/members` / `DELETE /teams/{id}/members/{userId}` to move people, `PATCH /users/{id}` to change role, `DELETE /users/{id}` to offboard (deactivates; `POST /users/{id}/reactivate` undoes it).\n\n**Keep routing rules in version control**\n`GET /automation-rules` returns every rule as the exact JSON the engine runs (conditions + actions). Commit that to your repo; on change, `PATCH /automation-rules/{id}` (or `POST` a new rule) from CI. Rule bodies keep the engine's own camelCase keys inside `conditions`/`actions` so an export re-applies verbatim; tag actions carry tag *names*. Who changed which rule and when is recorded in the workspace activity log.\n\n**Keep the AI knowledge fresh from a pipeline**\nCreate one `POST /knowledge-sources` (`kind: \"text\"`) per document in your source of truth and remember the returned `id`. When the document changes, `PATCH /knowledge-sources/{id}` with the new `content` — Elvo re-chunks and re-embeds asynchronously (`status` goes `processing` → `ready`); a PATCH whose title and content match what is stored is a no-op (no re-embedding, no status change), so a pipeline can PATCH on every run. URL sources can be re-fetched with `POST /knowledge-sources/{id}/sync`. Documents (pdf, docx, …) go in as `file` sources via `POST /knowledge-sources/files`, and `PUT /knowledge-sources/{id}/file` swaps the file behind one while keeping its id — the nightly \"re-upload the current price list\" job.\n\n**Pull reporting**\n`GET /reports/performance?period=last_30_days` returns the Frammistaða dashboard as JSON — first-reply and resolution times, volumes, AI share, per-agent and per-team stats — with the previous period for comparison.\n\n## Webhooks\n\nRegister a webhook endpoint and Elvo POSTs you a signed JSON payload whenever a subscribed event happens — no polling.\n\n**Events**\n\n- `conversation.created` — a new conversation landed (any channel, including ones you create via this API). Two gaps to know about: conversations an agent composes outbound from the dashboard start as silent drafts and never emit this event (you'll see their first `comment.created` instead — treat unknown conversation ids by fetching `GET /conversations/{id}`), and historical mailbox imports never emit webhooks at all.\n- `conversation.updated` — status, assignee, team, subject, tags, contact, or snooze state changed. Deletion arrives as `conversation.updated` with `data.conversation.status: \"deleted\"` — there is no separate deleted event, and a conversation that is purged entirely (hard delete) may produce no event.\n- `comment.created` — a new customer message or agent reply (check `data.comment.type`). **Internal notes are never delivered.** Comments your own integration creates via `POST /conversations/{id}/comments` also fire this event back at you — record the comment `id` from your POST responses and skip matching deliveries to avoid loops.\n\n**Register an endpoint** (requires a write-scope token):\n\n```bash\ncurl -X POST https://elvo.is/api/public/v1/webhooks \\\n -H \"Authorization: Bearer elvo_...\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"url\":\"https://example.com/elvo-webhook\",\"events\":[\"conversation.created\",\"comment.created\"]}'\n```\n\nThe response includes a `secret` (`whsec_...`) — shown **once**, store it safely.\n\n**Verify signatures.** Every delivery carries three headers: `Elvo-Webhook-Id`, `Elvo-Webhook-Timestamp` (unix seconds), and `Elvo-Webhook-Signature` (`v1=`). The signature is HMAC-SHA256 over `..` using your endpoint secret:\n\n```js\nimport { createHmac, timingSafeEqual } from 'node:crypto'\n\nfunction verify(req, rawBody, secret) {\n const id = req.headers['elvo-webhook-id']\n const ts = req.headers['elvo-webhook-timestamp']\n const expected = 'v1=' + createHmac('sha256', secret).update(`${id}.${ts}.${rawBody}`).digest('hex')\n const given = req.headers['elvo-webhook-signature'] ?? ''\n return given.length === expected.length && timingSafeEqual(Buffer.from(given), Buffer.from(expected))\n}\n```\n\nUse the **entire secret string as the HMAC key, including the `whsec_` prefix** — do not strip or base64-decode it. Reject deliveries whose timestamp is older than a few minutes to prevent replay.\n\n**Delivery semantics**\n\n- At-least-once: respond with any 2xx within 10 seconds. Anything else is retried for **3 total attempts within about a minute** (immediately, then ~20s and ~40s later); dedupe on the payload `id`, which is stable across retries.\n- Redirects are **not** followed — a 3xx response counts as a failed delivery. Register the final URL.\n- A burst of changes can produce several `conversation.updated` events for one conversation. Payloads carry the conversation's state *at delivery time*, so order by `data.conversation.updated_at` (not the event's `created_at`) when reconciling.\n- An endpoint is automatically disabled (`active: false` with a `disabled_reason`) after 25 consecutive failed delivery attempts. Re-enable with `PATCH /webhooks/{id} {\"active\": true}` after fixing your receiver — this resets the failure counter (changing `url` alone does not). Events that occur while an endpoint is disabled are **not** queued or replayed; after re-enabling, reconcile by listing conversations.\n- To rotate a signing secret: register a second endpoint (same host, different path), verify against both secrets during cutover, then delete the old endpoint.\n- Destination URLs must be public https addresses; one endpoint per URL per organization.\n\n## Custom integrations — your data in AI answers\n\nThe REST API above is one half of the integration story. The other half runs in the opposite direction: Elvo pulls live context out of **your** systems and puts it in front of agents and the AI. Built-in connectors exist for DK, Business Central, Payday, Regla, Shopify, WooCommerce, HubSpot, Dropp, and Abler — and a **custom integration** covers everything else with a single HTTPS endpoint that you host.\n\nWhenever an agent opens a conversation or the AI drafts a reply, Elvo POSTs the contact's identity and their latest message to your endpoint. You look the customer up — by email, or by parsing an order/member/shipment id out of the message — and respond with structured JSON: `fields` render in the agent's sidebar, `aiSummary` (or `markdown`) is what the AI reply draft sees.\n\n**Request** (Elvo → your endpoint):\n\n```\nPOST \nAuthorization: Bearer \nContent-Type: application/json\nX-Elvo-Organization: \n\n{\n \"email\": \"customer@example.com\",\n \"name\": \"Customer Name\",\n \"organizationId\": \"uuid\",\n \"ticketId\": \"uuid\" | null,\n \"ticketSubject\": \"Question about order 12345\" | null,\n \"ticketBodyExcerpt\": \"first ~2 KB plain text of the latest customer message\" | null,\n \"customerMessage\": \"the FULL plain text of the latest customer message\" | null\n}\n```\n\n**Response** — `200` with data, or `404` when there's no match (any other status or a timeout is logged and Elvo proceeds without your data):\n\n```json\n{\n \"title\": \"Order #12345\",\n \"subtitle\": \"Acme ehf.\",\n \"fields\": [\n { \"label\": \"Status\", \"value\": \"Shipped\", \"link\": \"https://internal.example.com/orders/12345\" },\n { \"label\": \"ETA\", \"value\": \"2026-05-09\" }\n ],\n \"aiSummary\": \"Order 12345 shipped 2026-05-02; ETA 2026-05-09; customer is on the corporate plan.\"\n}\n```\n\n**Behavior contract**: 5-second timeout; successful responses cached ~5 minutes per (integration, contact email, customer message); responses capped at 256 KB; HTTPS only, no private/internal hostnames; reject any request whose bearer token doesn't match the one Elvo generated for you.\n\nSet it up under **Settings → Integrations → Custom integration** — Elvo generates a complete setup brief there (this contract plus sample Node and Python servers) that you can hand directly to the engineer building the endpoint.\n\n## Embedding the chat widget (Spjallþjónn)\n\nThe customer-facing conversation surface is the Elvo chat widget — an AI agent that answers visitors from your knowledge and hands complex cases to your team. Embed it on any site by pasting the snippet shown in **Settings** when you set up the Spjallþjónn:\n\n```html\n\n\n```\n\nWidget sessions are anonymous; when a conversation needs follow-up, the AI asks the visitor for their name and email and links the conversation to a contact. Widget conversations land in your workspace like any other channel — you can read them through this API and receive them via webhooks.\n\n**A note on scope.** API tokens act as the team member who created them: this is an agent-scoped API, built for automations and systems working *alongside* your team. There is no end-user-scoped token today — an end user of your product can't call this API to hold their own conversation. For customer-facing experiences, embed the chat widget. If your use case needs programmatic end-user conversations (a native app, an embedded portal), email **elvo@elvo.is** — we want to hear about it.\n\n## Revoking a token\n\nAny admin can revoke a token at any time from the same settings page. Revocation takes effect immediately — the next request returns 401.\n\n## Support\n\nQuestions or missing endpoints? Email **elvo@elvo.is**.\n"},"servers":[{"url":"https://elvo.is/api/public/v1","description":"Production"}],"security":[{"bearerAuth":[]}],"tags":[{"name":"Conversations","description":"Customer conversations (also called tickets). Read, update status/tags/assignee/team, snooze. Status values: `open`, `pending`, `resolved`, `ignored`, `deleted` (there is no `closed`; see **Conversation statuses** above)."},{"name":"Comments","description":"Messages and internal notes attached to a conversation. Send replies and add notes."},{"name":"Chats","description":"Internal team chats (DMs, group chats, team/org channels). Threads with teammates — distinct from customer conversations. See the two-axis model below."},{"name":"Contacts","description":"People who have written in. Address book entries and ad-hoc senders."},{"name":"Mentions","description":"Where the token's user was @-mentioned, across conversations and chats. The bell, as an API."},{"name":"Organization","description":"The workspace owning the API token."},{"name":"Attachments","description":"Upload files to include in replies via `attachment_ids`."},{"name":"Webhooks","description":"Outbound webhook endpoints — get notified of events instead of polling."},{"name":"Users","description":"Team members in the organization. Members join through invitations; leaving is a soft deactivation that keeps their history and can be undone. Role changes, deactivation and reactivation need an admin-owned token."},{"name":"Invitations","description":"Pending invitations to join the organization. Creating one sends the invitee an email with a link; on acceptance they become a User with the given role and team memberships. Writing needs an admin-owned token."},{"name":"Teams","description":"Teams group conversations, channels and members into separate inboxes. Every organization has one default team (channels without an explicit team route there). Reads are open to any member; creating, editing, deleting and managing members require an admin-owned token."},{"name":"Channels","description":"The inbound channels an organization receives conversations on: forwarding addresses and synced mailboxes, Meta pages (Messenger, Instagram), WhatsApp numbers, the website widget and the phone line. Read-only for now — connecting a channel involves an OAuth consent or a DNS/forwarding step that has to happen in the dashboard (Settings → Tölvupóstur / Samfélagsmiðlar / Spjallþjónn). Every channel routes to exactly one team; `team_id` is where its conversations land."},{"name":"Tags","description":"The organization's tag vocabulary (\"merki\"). Tags are first-class rows with an id, a name that is unique per organization case-insensitively, an optional palette color and emoji, and a usage count. Conversations reference tags by NAME (`tags` on a conversation, the `tag` list filter); this resource manages the vocabulary itself. Any member's token may read and write tags, as in the dashboard."},{"name":"Canned responses","description":"Saved reply templates (\"stöðluð svör\") agents insert from the composer. A response is available to everyone (empty `team_ids`) or restricted to one or more teams. `exclude_from_ai: true` keeps a response out of AI reply drafts while agents can still insert it. Any member's token may read and write them, as in the dashboard; the list applies the same visibility rule the composer does for the token's owner."},{"name":"Automation rules","description":"Routing rules the engine evaluates against every new inbound conversation, in `priority` order (lower first), applying each matching rule's actions until one says `stop_processing_more_rules`.\n\nAny member's token can read and write rules (the dashboard grants the same). The rule JSON — `conditions` and `actions` — is the engine's own format, returned verbatim so you can keep rules in version control: `GET` the list, commit it, and `PATCH` a rule with the same objects to re-apply. **Inside those two arrays the keys are camelCase** (`toEmail`, `includeAttachments`, `userIds`, `teamId`, `roundRobin`, `onlyOnline`) — the one deliberate exception to this API's snake_case, kept so exported rules round-trip byte-for-byte. Everything at the top level of a rule (`is_active`, `condition_logic`, `created_at`, …) is snake_case as usual.\n\n`add_tag` / `remove_tag` carry tag **names**, not ids, like `tags` everywhere else on this API. Unknown names are created on first use.\n\nThere is no server-side rule history: Elvo's activity log records who changed which rule and when, and the full rule JSON is what you keep in git."},{"name":"Knowledge","description":"The AI knowledge base (Þekking in the dashboard): the documents the AI agents answer from. Each source is chunked and embedded asynchronously — a new or changed source is `status: processing` until the job finishes, then `ready` (with `chunk_count`) or `error` (with `error_message`).\n\n**Keeping the knowledge fresh from your own system.** Create one text source per document you own (`POST` with `kind: \"text\"`), remember its `id`, and `PATCH` its `content` whenever the document changes. A PATCH whose `title`/`content` match what is stored is a no-op (200, no re-embedding, `status` unchanged), so a pipeline can safely PATCH on every run. URL and Google Docs/Sheets sources are refreshed by Elvo on a schedule; `POST /knowledge-sources/{id}/sync` forces a refresh, and unchanged extracted text skips re-embedding by content hash.\n\n**Files.** `POST /knowledge-sources/files` uploads a document (pdf, txt, md, docx, xlsx, xls, csv; up to 4 MB) as a `file` source, and `PUT /knowledge-sources/{id}/file` swaps the document behind an existing file source while keeping its id and title — so a nightly job can re-upload the current price list, or an agent can replace an outdated PDF. A replacement whose extracted text is unchanged skips re-embedding. Files over 4 MB are dashboard-only (the platform caps API request bodies at ~4.5 MB).\n\nReads are open to any token; creating, updating, deleting and syncing require an admin-owned token."},{"name":"Reports","description":"Read-only reporting. `GET /reports/performance` returns exactly the data behind the dashboard's **Frammistaða** (performance) tab — the same metric definitions, the same 5-minute cache — so a number in the API always matches the number on screen. The Frammistaða feature is included on **Vöxtur (Pro)** and above. Access follows the dashboard rule: organization admins always; other members only when the organization has opened the tab to all members (Settings → Frammistaða). `period` and `comparison` values use the API's own snake_case spellings (`last_30_days`, `previous_period`, …), not the dashboard's internal ones."},{"name":"Me","description":"The token owner — the member who created the token. Out of office (Fjarvera) is set here: a purple presence dot and a banner for teammates in internal chats, and one auto-reply per sender from the member's personal connected mailboxes. It is user-level, so one status covers every organization the member belongs to; other members see it as `out_of_office` on the User resource."}],"components":{"securitySchemes":{"bearerAuth":{"type":"http","scheme":"bearer","bearerFormat":"Elvo API Token"}},"schemas":{"Conversation":{"type":"object","properties":{"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"conversation_number":{"nullable":true,"type":"number"},"subject":{"type":"string"},"status":{"type":"string","enum":["open","pending","resolved","ignored","deleted"]},"contact_id":{"nullable":true,"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"assigned_to_id":{"nullable":true,"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"team_id":{"nullable":true,"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"channel":{"nullable":true,"description":"Where the conversation came in. Inbound channels use the `Channel.type` vocabulary (`email.postmark`, `email.gmail`, `email.microsoft`, `messenger`, `instagram`, `whatsapp`, `beacon_chat`, `beacon_form`, `voice`); conversations created through this API carry the `channel` given at creation (`webhook`, `manual`, `phone`). Null for legacy conversations without a recorded channel.","type":"string"},"channel_id":{"nullable":true,"description":"The `Channel.id` the conversation arrived on (the forwarding address, mailbox connection UUID, page id, phone-number id or widget UUID) — pair with `channel` to look it up in `GET /channels`. For widget conversations this is the beacon UUID. Null for voice calls, API-created conversations and legacy rows.","type":"string"},"tags":{"nullable":true,"description":"Tag names on the conversation, in the order they were added. Tags are an org-wide vocabulary (each also carries a color/emoji, managed in the dashboard); names are case-sensitive. Null when the conversation has no tags.","type":"array","items":{"type":"string"}},"created_at":{"type":"string","format":"date-time","pattern":"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"},"updated_at":{"type":"string","format":"date-time","pattern":"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$","description":"Last change: a new message, reply or internal note, or a change to status, assignee, team, tags, subject or snooze. Inbound email is stamped with its sent time, which can be slightly earlier than its arrival."},"resolved_at":{"nullable":true,"type":"string","format":"date-time","pattern":"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"},"snooze_until":{"nullable":true,"type":"string","format":"date-time","pattern":"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"},"snoozed_by_id":{"nullable":true,"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"snooze_discard_on_reply":{"type":"boolean"},"snooze_leave_in_inbox":{"type":"boolean"},"archived_at":{"nullable":true,"description":"When the conversation was archived (Geymsla). An archived conversation keeps its status but is out of every inbox view: auto-replies, for example, are born archived. Null when not archived.","type":"string","format":"date-time","pattern":"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"},"related_conversation_ids":{"type":"array","items":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"}},"contact":{"description":"The conversation's contact (id, email, name), or null when it has none. Omitted from webhook payloads.","example":{"id":"9c2e4f1a-7b3d-4e5f-8a6b-1c2d3e4f5a6b","email":"jon@example.is","name":"Jón Jónsson"},"nullable":true,"type":"object","properties":{"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"email":{"type":"string"},"name":{"nullable":true,"type":"string"}},"required":["id","email","name"]},"last_message_at":{"description":"When the newest customer message or agent reply was written (internal notes and system entries excluded). Null when there are none. Omitted from webhook payloads.","example":"2026-09-28T14:03:11.000Z","nullable":true,"type":"string","format":"date-time","pattern":"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"},"last_customer_message_at":{"description":"When the newest message from the customer arrived. Null when the customer has not written. Omitted from webhook payloads.","example":"2026-09-28T13:55:42.000Z","nullable":true,"type":"string","format":"date-time","pattern":"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"},"message_count":{"description":"Number of customer messages plus agent replies (internal notes, system entries and deleted messages excluded). Omitted from webhook payloads.","example":4,"type":"integer","minimum":-9007199254740991,"maximum":9007199254740991}},"required":["id","conversation_number","subject","status","contact_id","assigned_to_id","team_id","channel","channel_id","tags","created_at","updated_at","resolved_at","snooze_until","snoozed_by_id","snooze_discard_on_reply","snooze_leave_in_inbox","archived_at","related_conversation_ids"]},"Comment":{"type":"object","properties":{"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"conversation_id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"type":{"type":"string","enum":["customer","agent","system"]},"user_id":{"nullable":true,"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"contact_id":{"nullable":true,"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"},"content":{"type":"string","description":"The stored body, verbatim. `content_format` says whether it is HTML or plain text. Agents that want text should read `content_text` instead."},"content_format":{"type":"string","enum":["html","text"],"description":"`html` for most email and composer replies. `text` for internal notes and chat-style channels, which are plain text with a small markdown subset (`**bold**`, `*italic*`, `` `code` ``, bare URLs, `@[Name]` mentions)."},"content_text":{"type":"string","description":"Plain-text rendering of `content`: `