> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudhumans.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Find a conversation by any identifier

> Locates conversations from an identifier in whatever form you have it — the number in the dashboard URL (**display_id**), the ticket id in your own helpdesk (Zendesk, Intercom and the like), or the conversation **uuid**. Every interpretation that matches is returned, newest first, capped at 10, and `matched_by` names the one that matched. Visibility follows the same rule as the list: an administrator token reaches every inbox of the account, an agent token only its own inbox memberships. An empty `matches` means the id does not exist on this account or is outside the token's reach — the two are deliberately indistinguishable.

export const CloudChatYourValues = () => {
  const STORAGE_KEY = "cloudchat-api-selected-account";
  const CREDENTIALS_HREF = "/api-reference/cloudchat/credentials";
  const [saved, setSaved] = useState(null);
  const [ready, setReady] = useState(false);
  useEffect(() => {
    let value = null;
    try {
      const raw = window.localStorage.getItem(STORAGE_KEY);
      if (raw) {
        const parsed = JSON.parse(raw);
        if (parsed && parsed.instance && parsed.account) {
          value = {
            instance: String(parsed.instance),
            account: String(parsed.account),
            name: typeof parsed.name === "string" && parsed.name ? parsed.name : null
          };
        }
      }
    } catch (error) {
      value = null;
    }
    setSaved(value);
    setReady(true);
  }, []);
  const shell = "not-prose rounded-xl border border-gray-200 dark:border-white/10 bg-gray-50 dark:bg-white/5 px-4 py-3 mb-6";
  if (!ready || !saved) {
    return <div className={shell}>
        <p className="text-sm text-gray-600 dark:text-gray-400">
          Every request below needs your <code>cloudchat-instance</code> header and your account
          id.{" "}
          <a href={CREDENTIALS_HREF} className="underline underline-offset-2">
            Paste your token
          </a>{" "}
          and they will show up here, ready to copy.
        </p>
      </div>;
  }
  return <div className={shell}>
      <div className="flex flex-wrap items-baseline gap-x-6 gap-y-2">
        <div>
          <span className="text-xs uppercase tracking-wide text-gray-500 dark:text-gray-400">
            cloudchat-instance
          </span>
          <span className="ml-2 font-mono text-sm text-gray-900 dark:text-gray-100">
            {saved.instance}
          </span>
        </div>
        <div>
          <span className="text-xs uppercase tracking-wide text-gray-500 dark:text-gray-400">
            accountId
          </span>
          <span className="ml-2 font-mono text-sm text-gray-900 dark:text-gray-100">
            {saved.account}
          </span>
        </div>
        {saved.name && <span className="text-sm text-gray-600 dark:text-gray-400">{saved.name}</span>}
        <a href={CREDENTIALS_HREF} className="text-sm text-gray-500 dark:text-gray-400 underline underline-offset-2">
          Change
        </a>
      </div>
    </div>;
};

<CloudChatYourValues />


## OpenAPI

````yaml api-reference/specs/cloudchat/v1.json GET /v1/accounts/{accountId}/conversations/find
openapi: 3.0.1
info:
  title: Cloud Chat API
  version: v1
  description: >-
    The curated public surface of Cloud Chat. Every call needs two things: the
    Bearer token from `POST /auth/v1/signin`, and the `cloudchat-instance`
    header that says which Cloud Chat instance your company lives on.


    If you don't know your instance value, the [Find your
    credentials](/api-reference/cloudchat/credentials) page reads it out of your
    own token in the browser.
servers:
  - url: https://api.cloudhumans.com/cloudchat
    description: Production
security:
  - bearerAuth: []
tags:
  - name: Canned Responses
    description: >-
      Canned responses — the shortcuts agents expand while replying. Each one
      belongs to a single account and is identified by its short code.
  - name: Conversations
    description: >-
      Read-only access to the conversations of an account. What you can see
      follows the same rule as the dashboard: an administrator token sees every
      inbox, an agent token only the inboxes it is a member of.
  - name: Help Center
    description: >-
      Portals, categories and articles of the help center — the public FAQ your
      customers read.
  - name: Uploads
    description: Store the images help center articles embed.
  - name: Labels
    description: >-
      Read-only access to the labels an account has defined. A label is a tag
      conversations and contacts carry; this endpoint only lists the label
      definitions themselves.
  - name: Inboxes
    description: >-
      Read-only access to the inboxes a token can see — every inbox of the
      account for an administrator, only its memberships for an agent. Never
      includes the channel's credentials.
  - name: Agents
    description: >-
      Read-only access to the human and AI agents of an account. A hidden admin
      (the platform's own support user) never appears, on the list or by id.
  - name: Teams
    description: >-
      Teams group agents for assignment. Listing and reading are open to any
      member; creating and updating a team, and managing its membership, require
      an administrator token. A system-managed team (provisioned by the
      platform) can be read like any other but never updated.
  - name: Macros
    description: >-
      Macros bundle a sequence of actions an agent runs against a conversation
      from the dashboard. This surface lets you list, read and write macro
      definitions — running one is not part of the v1 contract. A macro is
      either `global` (visible to the whole account) or `personal` (visible only
      to its author); an agent token can only create personal macros.
  - name: Automation Rules
    description: >-
      Read-only access to the account's automation rules — administrator only.
      An agent token gets a 403 on every operation in this group.
  - name: Availability Reasons
    description: >-
      The reasons an agent can go `busy` for, configured per account. Listing is
      open to any member; creating, updating and deleting require an
      administrator token. Deleting is a soft delete — the reason disappears
      from listings but agents' past availability history keeps referencing it.
  - name: Native Attribute Requirements
    description: >-
      Which native conversation attributes (priority, assignee, tag, team) the
      account requires agents to fill before resolving a conversation. Listing
      is open to any member; requiring and un-requiring need an administrator
      token. Deleting a requirement is reversible — require the same key again
      to restore it.
paths:
  /v1/accounts/{accountId}/conversations/find:
    parameters:
      - $ref: '#/components/parameters/CloudChatInstance'
      - $ref: '#/components/parameters/AccountId'
    get:
      tags:
        - Conversations
      summary: Find a conversation by any identifier
      description: >-
        Locates conversations from an identifier in whatever form you have it —
        the number in the dashboard URL (**display_id**), the ticket id in your
        own helpdesk (Zendesk, Intercom and the like), or the conversation
        **uuid**. Every interpretation that matches is returned, newest first,
        capped at 10, and `matched_by` names the one that matched. Visibility
        follows the same rule as the list: an administrator token reaches every
        inbox of the account, an agent token only its own inbox memberships. An
        empty `matches` means the id does not exist on this account or is
        outside the token's reach — the two are deliberately indistinguishable.
      operationId: findMyConversation
      parameters:
        - name: id
          in: query
          required: true
          description: >-
            The identifier exactly as you have it, in any of the three forms:
            the conversation number from the dashboard URL (display id), the
            ticket id in your own helpdesk, or the conversation uuid. The
            operation tries every interpretation the value's shape allows and
            reports in `matched_by` which one matched — send it as it came,
            without converting or padding it.
          schema:
            type: string
            example: '233206'
      responses:
        '200':
          description: >-
            The conversations the identifier matched — possibly none, which is a
            normal answer, not an error.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ConversationFindResult'
        '400':
          $ref: '#/components/responses/BadRequest'
        '401':
          $ref: '#/components/responses/Unauthorized'
        '403':
          $ref: '#/components/responses/Forbidden'
        '404':
          $ref: '#/components/responses/NotFound'
        '429':
          $ref: '#/components/responses/TooManyRequests'
        '500':
          $ref: '#/components/responses/InternalError'
components:
  parameters:
    CloudChatInstance:
      name: cloudchat-instance
      in: header
      required: true
      description: >-
        Your Cloud Chat instance ID — an integer, fixed for your company, told
        at onboarding. [The API
        overview](/api-reference/cloudchat/overview#two-headers-every-call)
        explains how instances work, how to find yours, and the errors a wrong
        or missing value produces.
      schema:
        type: integer
        example: 1
    AccountId:
      name: accountId
      in: path
      required: true
      description: >-
        Your Cloud Chat account. It has to be an account your token grants
        membership on, and it has to live on the instance in the
        `cloudchat-instance` header — the two travel together. Account numbers
        are only unique **within** an instance, so the same number is a
        different company on another instance. Usually a mismatched pair fails
        closed with a 401, because your user does not exist on the other
        instance — but if your identity happens to exist on both, the call
        succeeds against the other company's data, silently. Read it and you are
        looking at the wrong help center; write it and you have stored into the
        wrong account. Send the two values that were given to you together, and
        never try a number to see what answers.
      schema:
        type: integer
        example: 1
  schemas:
    ConversationFindResult:
      type: object
      required:
        - account_id
        - instance
        - matches
      properties:
        account_id:
          type: integer
          description: The account that was searched, echoing the request.
          example: 1
        instance:
          type: string
          nullable: true
          description: >-
            The Cloud Chat instance that answered — the same value you sent as
            `cloudchat-instance`. Filled in practice; if it comes back `null`,
            the value you sent stays authoritative.
          example: '1'
        matches:
          type: array
          description: >-
            Every conversation the identifier matched, newest first, capped at
            10. One helpdesk ticket id can correspond to several internal
            conversations — helpdesks that keep a single continuous thread per
            customer create one internal conversation per service episode — so
            more than one match is a normal outcome, not an error. Use
            `created_at`, `last_activity_at` and `status` to pick the one the
            report is about. Empty means the id does not exist on this account
            or is outside the token's reach, deliberately indistinguishable.
          items:
            $ref: '#/components/schemas/ConversationMatch'
    ConversationMatch:
      type: object
      required:
        - matched_by
        - display_id
        - uuid
        - helpdesk_id
        - status
        - created_at
        - last_activity_at
        - inbox
        - contact_name
      properties:
        matched_by:
          type: string
          enum:
            - display_id
            - helpdesk_id
            - uuid
          description: >-
            Which interpretation of `id` this conversation matched: its number
            in the dashboard URL (`display_id`), its ticket id in your own
            helpdesk (`helpdesk_id`), or its canonical uuid (`uuid`).
          example: display_id
        display_id:
          type: integer
          description: >-
            The conversation number shown in the dashboard URL — the
            `conversationId` that [Get a
            conversation](/api-reference/cloudchat/endpoints/get-a-conversation)
            and [List
            messages](/api-reference/cloudchat/endpoints/list-conversation-messages)
            take.
          example: 1042
        uuid:
          type: string
          description: >-
            The conversation's canonical id — the same `cloudChatId` the ClaudIA
            API takes in [Get a conversation
            summary](/api-reference/claudia/endpoints/get-conversation-summary)
            and [Get a message
            trace](/api-reference/claudia/endpoints/get-message-trace).
          example: 495fd1e4-dbbb-46c6-8463-55cbf7b1d085
        helpdesk_id:
          type: string
          nullable: true
          description: >-
            Ticket id in your own helpdesk. On accounts whose helpdesk is Cloud
            Chat itself it is `null` or equals `display_id`; on accounts
            mirrored from an external helpdesk it is that helpdesk's id. Older
            mirrored conversations can carry `null` here too — those still
            resolve by uuid.
          example: '233206'
        status:
          type: string
          enum:
            - open
            - resolved
            - pending
            - snoozed
            - proactive
          description: >-
            Where the conversation is in its lifecycle — part of what tells
            several matches apart.
          example: open
        created_at:
          type: string
          format: date-time
          description: >-
            When it was created. ISO 8601, always UTC, milliseconds included.
            Together with `last_activity_at` and `status`, this is what tells
            several matches apart.
          example: '2026-08-13T19:09:51.482Z'
        last_activity_at:
          type: string
          format: date-time
          description: >-
            When the last message or activity happened — tells an ongoing
            conversation from an abandoned one.
          example: '2026-08-13T19:42:07.115Z'
        inbox:
          allOf:
            - $ref: '#/components/schemas/ConversationMatchInbox'
          description: >-
            The inbox the conversation lives in — tells the channel the customer
            used.
        contact_name:
          type: string
          nullable: true
          description: >-
            Display name of the customer on the other side; `null` when the
            conversation has no contact or the name is unknown.
          example: Ana
    Error:
      type: object
      description: The error envelope every Cloud Chat API response uses.
      required:
        - error
      properties:
        error:
          type: object
          required:
            - code
            - message
          properties:
            code:
              type: string
              description: >-
                The stable, machine-readable reason. Branch on this, never on
                `message`.
              enum:
                - unauthorized
                - forbidden
                - not_found
                - validation_failed
                - bad_request
                - internal_error
              example: not_found
            message:
              type: string
              description: >-
                The reason in words, localized to your account's language
                (English, Spanish or Brazilian Portuguese; English when the
                account is set to anything else). Wording changes with the
                account and between releases, so never match on it.


                Two cases stay in English whatever the account is set to:
                `unauthorized`, decided before any account is known, and the
                account-level `not_found`, which must not reveal the account's
                language.
              example: Resource could not be found.
            details:
              type: array
              description: >-
                Present on some rejections — a 400 for a refused query parameter
                or upload mode, for example. One entry per offending field,
                localized to the account's language like `message` — match on
                `code` and `field`, never on the text.
              items:
                type: object
                required:
                  - field
                  - code
                  - message
                properties:
                  field:
                    type: string
                    description: Which request field the rule was about.
                  code:
                    type: string
                    description: Stable, machine-readable reason.
                  message:
                    type: string
                    description: The rule in words.
    GatewayError:
      type: object
      description: >-
        Rejected by the gateway before Cloud Chat saw it, so it does not use the
        `error` envelope.
      required:
        - message
      properties:
        message:
          type: string
          example: API rate limit exceeded
        request_id:
          type: string
          description: Gateway request id. Quote it when reporting a problem.
          example: f3f7567638d4b65a8003057d0c77d275
    ConversationMatchInbox:
      type: object
      required:
        - id
        - name
        - channel_type
      properties:
        id:
          type: integer
          description: >-
            The inbox id — the same value the `inbox_id` filter of [List
            conversations](/api-reference/cloudchat/endpoints/list-conversations)
            takes.
          example: 3
        name:
          type: string
          description: The inbox name as shown in the dashboard.
          example: WhatsApp
        channel_type:
          type: string
          nullable: true
          description: >-
            The channel implementation behind the inbox, e.g.
            `Channel::Whatsapp`. Filled in practice; `null` on the rare inbox
            stored without one.
          example: Channel::Whatsapp
  responses:
    BadRequest:
      description: >-
        The request itself is malformed, before any value is validated:


        - a body that isn't valid JSON, or one with no `canned_response`
        wrapper,

        - a `canned_response` that isn't an object (`{"canned_response":
        "text"}`),

        - `page`, `per_page`, `search` or `sort` sent as an array or a nested
        object (`?page[]=1`, `?sort[x]=y`) instead of a plain value,

        - **the `cloudchat-instance` header missing or holding a value we don't
        route,**

        - an `accountId` that is not a number — including the literal
        `{accountId}` that some API clients send when the argument is left
        unset. This one answers with the normal envelope and `error.details`
        naming `accountId`, and it is deliberately **not** a 404: a 404 would
        mean the account cannot be reached, while this means the value was never
        an account id at all, so re-read the argument instead of trying other
        numbers.


        **Two different shapes answer with 400, and the difference will bite you
        on day one.** That last case is rejected before the request reaches the
        API, so `error` is a plain **string** instead of the usual object:


        ```json

        { "error": "<human-readable message>" }

        ```


        Every other 400 uses the normal envelope, where `error` is an object
        with `code` and `message`. Reading `error.code` without checking the
        type first throws on the missing-header case — which is the most likely
        400 of your first integration. Check `typeof error === "string"` first,
        or read `error?.code` defensively.


        A 400 always means fix the request shape; it never means a value was
        rejected. Rejected values are 422.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
          example:
            error:
              code: bad_request
              message: The request is malformed.
    Unauthorized:
      description: >-
        No Bearer token, or one that is expired, malformed, or not a Cognito
        token. Sign in again for a fresh `id_token`.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
          example:
            error:
              code: unauthorized
              message: >-
                Authentication is required. Send a valid Bearer token in the
                Authorization header.
    Forbidden:
      description: >-
        You are a member of the account, but the account is suspended. Nothing
        on it can be read or written until that is resolved — talk to your
        CloudHumans contact.


        This is the only reason for a 403. Not being a member of the account is
        a 404, not a 403.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
          example:
            error:
              code: forbidden
              message: This account is suspended.
    NotFound:
      description: >-
        The resource is not there for you. Three situations answer with this
        code, and the first two apply to **every** endpoint — the account is
        resolved before anything else runs, so a list or a create fails this way
        too:


        - the account does not exist on this instance,

        - the account exists but your token has no membership on it,

        - on an endpoint that names one, the resource it names (a canned
        response, a portal, an article) does not exist where the path says it
        does.


        The first two are deliberately indistinguishable — same status, same
        body, and the message stays in English in both, since translating it
        would reveal the account's configured language. So you cannot use this
        endpoint to find out which account ids exist. The third case is
        localized like every other error, which is safe because you only reach
        it once membership is established.


        Either way a 404 is not worth retrying. Check the `accountId`, the
        `cloudchat-instance` value, and that your user is a member of the
        account.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
          example:
            error:
              code: not_found
              message: Resource could not be found.
    TooManyRequests:
      description: >-
        Rate limited per source IP. Note the envelope: this one is `{ "message":
        ... }`, because the request never reached the API.


        Don't hardcode the limit — read it from the response. `Retry-After` says
        how many seconds to wait, and every response (not just this one) carries
        `ratelimit-limit`, `ratelimit-remaining` and `ratelimit-reset`, the last
        in seconds.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/GatewayError'
          example:
            message: API rate limit exceeded
    InternalError:
      description: >-
        Something failed on our side. The response never carries the underlying
        error, but it is reported to our monitoring automatically — no need to
        file anything for a one-off.


        Retrying is reasonable, with one caveat on `POST`: a 500 does not prove
        the write did not happen, so a retry can come back `422` with
        `short_code` already taken. That 422 means the first attempt succeeded —
        list the account and confirm before treating it as a failure.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
          example:
            error:
              code: internal_error
              message: An unexpected error occurred. Please try again later.
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: >-
        The `id_token` from `POST /auth/v1/signin`, sent as `Authorization:
        Bearer <id_token>`. Not the `access_token` — that one does not carry the
        identity Cloud Chat authorizes on.

````