> ## Documentation Index > Fetch the complete documentation index at: https://docs.clarifeye.ai/llms.txt > Use this file to discover all available pages before exploring further. # Search interview transcripts > Keyword search over interview transcripts, returning short snippets that point at where something was said (agent-oriented: read the interview itself for the full context). The query is split into whitespace-separated keywords; a message matches when it contains any term (case-insensitive substring), so extra words broaden rather than narrow the search and there is no phrase matching. Punctuation is stripped from each term's edges, and stopwords and single-character terms are dropped — a query consisting only of those is rejected with 400. Only conversational message turns are searched — tool-call payloads and reasoning entries never match. Hits are ranked by distinct terms matched, then interview recency, and capped at 3 per interview and 30 in total. All interview conversation types (onboarding, interview, guided-interview, imported-interview) are always searched. Visibility scoping matches the interviews list (non-admins only search their own or assigned interviews). ## OpenAPI ````yaml /api-reference/openapi-full.yaml get /projects/{project_id}/interviews/search-transcripts/ openapi: 3.0.3 info: title: Clarifeye Platform API — Full API Documentation description: > Complete REST API reference for the Clarifeye Platform. Documents every endpoint exposed by the platform — the public surface plus the advanced surface: pipeline customization (extraction flows, pipeline runs, warehouse tables, document tag/metadata configuration), the pre-MCP AI surface (agent settings, playground conversations, conversation-scoped feedback views, notifications), and the impersonation header. New AI integrations should consume knowledge via MCP rather than the conversation/agent-settings endpoints documented here. ## Authentication All endpoints require authentication. Include the Authorization header in every request using either format: - `Authorization: Token ` - `Authorization: Bearer ` ## Service accounts and API keys Integrations authenticate with an **API key** of a **service account**: - `Authorization: Bearer ` (keys start with `cfk_`) A service account is an ordinary member (role `member`) of one organization that cannot log in. Organization admins create it and mint its keys on the organization's *Service accounts* page (`/organizations/{id}/service-accounts/`, `/organization-api-keys/`), and give it access to knowledge stores with ordinary store permissions. A key is valid on every endpoint and acts as its service account: it reaches exactly the stores, with exactly the rights, the account was given. An account can hold several keys (each with its own name, optional expiry and revocation), so a key can be rotated without changing identity. A refused key answers **403** with one of: `Invalid API key.`, `API key revoked.`, `API key expired.`, `API key disabled.` (the service account is disabled). Any valid key may also call `POST /organizations/{id}/provision-user/` and `POST /organizations/{id}/deprovision-user/` for its own organization (the `{id}` in the path must be the key's organization). The email domains these may pre-create accounts for are configured by Clarifeye on the organization (`allowed_provisioning_domains`). ## Impersonation Certain endpoints support user impersonation for creating or listing data on behalf of other users. This is useful for integrating external systems that need to attribute actions to specific users. **Header:** `X-Impersonate-Email` **Required Permission:** `CAN_IMPERSONATE_OTHER_USERS` (for a person, contact Clarifeye to enable it; org admins grant it to a service account on the organization's Service accounts page) **Behavior:** - If the header is provided and the impersonator has the required permission, the action is performed as the target user - If the target user is not found, the request proceeds as the original authenticated user - If the target user does not have access to the project, the request proceeds as the original authenticated user - If the impersonator lacks the `CAN_IMPERSONATE_OTHER_USERS` permission, the header is ignored **With an API key** the request fails instead (**403**) whenever impersonation cannot happen: missing permission, unknown target, target without access to the store, target that is itself a service account, or an endpoint outside a store. A key never silently acts as its own service account when impersonation was asked for. version: 1.0.0 contact: name: Clarifeye Support servers: - url: https://eu.app.clarifeye.ai/api/v1 description: EU - url: https://us.app.clarifeye.ai/api/v1 description: US security: - BearerAuth: [] - TokenAuth: [] tags: - name: Users description: Manage users within a project - name: Invitations description: Manage project invitations - name: Documents description: Manage documents within a project - name: Agent Settings description: Manage AI agent configurations - name: Conversations description: Create and interact with AI-powered conversations - name: Interviews description: Assign and review structured interview conversations - name: Meetings description: >- Meetings Clara attends as a bot (Recall.ai) — live transcript, live insights, recording, and calendar scheduling (CLA-1843). Store admins only. - name: Feedback description: >- Submit and review feedback — standalone (content-only), agent-submitted (MCP), or linked to a conversation message - name: Tools description: Execute configured AI tools with custom parameters - name: Tables description: Perform CRUD operations on warehouse tables - name: Notifications description: Manage project-scoped notifications for users - name: Extraction Flows description: >- Manage extraction flows (auto-sync DAGs) — list, run, inspect statistics, update, and publish - name: Object Extractors description: | Extract structured data (instances of a Pydantic model) from chunks or blocks of documents. Update auto-creates a new `ObjectExtractorVersion` when version-bearing fields change. - name: Tag Extractors description: | Apply hierarchical metadata tags to chunks or documents using an LLM. Update auto-creates a new `TagExtractorVersion` when version-bearing fields change. - name: Chunks Extractors description: | Segment parsed documents into chunks for downstream processing. Update auto-creates a new `ChunksExtractorVersion` when version-bearing fields change. - name: Parsing Extractors description: | Convert source documents to text blocks via the parsing pipeline. Update auto-creates a new `ParsingExtractorVersion` when version-bearing fields change. - name: Document Filter Extractors description: | Restrict a downstream pipeline branch to documents matching a filter. Update auto-creates a new version when the filter changes. - name: Chunk Tag Filter Extractors description: | Restrict a downstream pipeline branch to chunks carrying specific tags. Update auto-creates a new version when the filter changes. - name: Document Tag Extractors description: | Apply a flat set of metadata tags to each document. Update auto-creates a new version when version-bearing fields change. - name: Tag Alerts Extractors description: | Run LLM-based alerts over already-extracted tag rows. Update auto-creates a new version when version-bearing fields change. - name: Object Alerts Extractors description: > Run LLM-based alerts over already-extracted object rows. Update auto-creates a new version when version-bearing fields change. - name: Imported Object Extractors description: | Hold objects imported from an external system (rather than extracted by an LLM). Useful for hydrating the warehouse with data produced outside the platform. - name: Pipeline Runs description: >- Inspect pipeline runs queued by extraction flows or other pipeline triggers — list runs and fetch the details/status of a single run - name: User Provisioning description: > Pre-create and de-provision org users via an org-scoped API key (`Authorization: Bearer `). The organization is resolved from the key. - name: Organization API Keys description: > Superuser management of org-scoped provisioning API keys. Minting and revoking are superuser-only; org admins can list/retrieve/reveal their own org's keys. - name: Design System Templates description: Reference/example files attached to a design template. - name: Artifacts description: | Knowledge-store artifact catalog — list artifacts, create/edit custom artifacts, manage scope membership, read and publish versions, configure the cohesion guide, and export/import the whole catalog. For type-aware reads and edits of artifact content, prefer the `read-write-*-artifact` tool endpoints. paths: /projects/{project_id}/interviews/search-transcripts/: get: tags: - Interviews summary: Search interview transcripts description: > Keyword search over interview transcripts, returning short snippets that point at where something was said (agent-oriented: read the interview itself for the full context). The query is split into whitespace-separated keywords; a message matches when it contains any term (case-insensitive substring), so extra words broaden rather than narrow the search and there is no phrase matching. Punctuation is stripped from each term's edges, and stopwords and single-character terms are dropped — a query consisting only of those is rejected with 400. Only conversational message turns are searched — tool-call payloads and reasoning entries never match. Hits are ranked by distinct terms matched, then interview recency, and capped at 3 per interview and 30 in total. All interview conversation types (onboarding, interview, guided-interview, imported-interview) are always searched. Visibility scoping matches the interviews list (non-admins only search their own or assigned interviews). operationId: searchInterviewTranscripts parameters: - $ref: '#/components/parameters/ProjectId' - name: query in: query required: true description: >- Search keywords (whitespace-separated; a message matches any term). Minimum 2 characters; stopwords and single-character terms are ignored. schema: type: string - name: campaign in: query description: >- Filter by campaign: a campaign UUID, or "none" for interviews without a campaign. schema: type: string - name: interview_ids in: query description: Comma-separated interview UUIDs to search within. schema: type: string responses: '200': description: Successful response content: application/json: schema: type: object properties: query: type: string terms: type: array description: The parsed search terms (unique, lowercased). items: type: string count_interviews_matched: type: integer description: >- Interviews with at least one matching message (before the total-hit cap). interviews_scanned: type: integer description: Candidate interviews whose transcripts were examined. scan_limit_reached: type: boolean description: > True when more interviews matched the prefilter than could be scanned, so older ones were not examined at all and matches may be missing entirely (not merely trimmed). truncated: type: boolean description: >- True when more matches exist than were returned (per-interview cap, total cap, or scan bound reached). hits: type: array items: type: object properties: interview_id: type: string format: uuid interview_name: type: string nullable: true type: type: string status: type: string nullable: true campaign: type: object nullable: true properties: id: type: string format: uuid name: type: string role: type: string nullable: true speaker: type: string description: Speaker name (imported transcripts only). timestamp: type: string nullable: true query_id: type: integer nullable: true description: >- Message identifier within the transcript, matching chat_history entries. snippet: type: string description: >- ~300-char window around the first matched term, ellipsis-trimmed. matched_terms: type: array items: type: string interview_total_matches: type: integer description: >- Matching messages in this interview (at most 3 become hits). '400': $ref: '#/components/responses/BadRequest' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/Forbidden' '404': $ref: '#/components/responses/NotFound' components: parameters: ProjectId: name: project_id in: path required: true description: UUID of the project schema: type: string format: uuid responses: BadRequest: description: Bad request - invalid parameters or request body content: application/json: schema: oneOf: - $ref: '#/components/schemas/Error' - $ref: '#/components/schemas/ValidationError' Unauthorized: description: Unauthorized - missing or invalid authentication content: application/json: schema: $ref: '#/components/schemas/Error' example: error: Authentication credentials were not provided. Forbidden: description: Forbidden - insufficient permissions content: application/json: schema: $ref: '#/components/schemas/Error' example: error: You do not have permission to perform this action. NotFound: description: Not found - resource does not exist content: application/json: schema: $ref: '#/components/schemas/Error' example: error: Not found. schemas: Error: type: object properties: error: type: string description: Error message example: error: User not found ValidationError: type: object additionalProperties: type: array items: type: string example: email: - This field is required. securitySchemes: BearerAuth: type: http scheme: bearer description: > Use `Authorization: Bearer `. The token is either a user token / OAuth access token, or a service-account API key (`cfk_...`). A key is valid on every endpoint and acts as its service account, an organization member with per-store permissions. Refused keys answer 403 with `Invalid API key.`, `API key revoked.`, `API key expired.` or `API key disabled.`. TokenAuth: type: apiKey in: header name: Authorization description: 'Use Authorization: Token ' ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.