> ## Documentation Index > Fetch the complete documentation index at: https://docs.nvisy.com/llms.txt > Use this file to discover all available pages before exploring further. # List recognizers > Returns the recognizers the engine has registered, grouped into NER and LLM — each with its name, optional description, and provider. Connection details and credentials are never exposed. ## OpenAPI ````yaml /api-reference/openapi.json get /capabilities/recognizers openapi: 3.1.0 info: title: Nvisy API summary: Document detection and redaction platform description: >- Nvisy provides intelligent detection of sensitive content in documents, redaction pipelines, and reviewer workflows. This API enables document upload, detection analysis, redaction, and collaborative review across your workspaces. termsOfService: https://nvisy.com/legal/terms-of-service contact: name: Nvisy Support url: https://nvisy.com email: hello@nvisy.com license: name: Apache-2.0 url: https://www.apache.org/licenses/LICENSE-2.0 version: 0.1.0 servers: [] security: [] tags: - name: Health description: Service health checks - name: Capabilities description: Read-only reference data describing this deployment - name: Accounts description: Account management and profile operations - name: Identities description: 'Account sign-in methods: password and linked providers' - name: Avatars description: Public avatar image serving - name: Authentication description: Login, signup, and token management - name: Workspaces description: Workspace creation and management - name: Activities description: Workspace activity log and export - name: Documents description: Document upload, download, and management - name: Analytics description: Aggregate metrics over a workspace's documents - name: Members description: Workspace member management - name: Invites description: Workspace invitation handling - name: API Tokens description: API token management - name: Connections description: External provider connections - name: Connection Syncs description: Connection synchronization runs - name: Providers description: Inference-provider configuration - name: Pipelines description: Redaction pipeline configuration - name: Detections description: Detection analysis and redaction - name: Redactions description: Redactions produced from a detection, with reviewer edits - name: Reviews description: Document reviews, the review queue, and their discussion - name: Policies description: Redaction policy configuration - name: Webhooks description: Webhook configuration - name: Notifications description: Account notification management paths: /capabilities/recognizers: get: tags: - Capabilities summary: List recognizers description: >- Returns the recognizers the engine has registered, grouped into NER and LLM — each with its name, optional description, and provider. Connection details and credentials are never exposed. responses: '200': description: The engine's registered recognizers, grouped by kind. content: application/json: schema: $ref: '#/components/schemas/RecognizerCatalog' '401': description: >- The serialized shape of an HTTP error: the inert wire/OpenAPI-schema view that [`Error`] renders to at the response boundary. It carries no builder logic — [`Error`] is the type handlers construct and thread through `Result`, and it builds an `ErrorResponse` directly in its `IntoResponse` impl. `context` and `status` are not part of the JSON body (`context` is logged, `status` sets the HTTP status line). [`Error`]: crate::response::Error content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - BearerAuth: [] components: schemas: RecognizerCatalog: description: The engine's registered recognizers, grouped by kind. type: object properties: llm: description: LLM recognizers. type: array items: $ref: '#/components/schemas/RegisteredRecognizer' ner: description: NER (named-entity recognition) recognizers. type: array items: $ref: '#/components/schemas/RegisteredRecognizer' required: - ner - llm ErrorResponse: description: >- The serialized shape of an HTTP error: the inert wire/OpenAPI-schema view that [`Error`] renders to at the response boundary. It carries no builder logic — [`Error`] is the type handlers construct and thread through `Result`, and it builds an `ErrorResponse` directly in its `IntoResponse` impl. `context` and `status` are not part of the JSON body (`context` is logged, `status` sets the HTTP status line). [`Error`]: crate::response::Error type: object properties: message: description: User-friendly error message safe for client display. type: string name: description: The error name/type identifier. type: string required: - name - message RegisteredRecognizer: description: |- Public view of one recognizer in the engine's NER or LLM lineup. Carries the name a request's allowlist picks by, an optional human-readable description, and a provider slug identifying the backend kind. Connection details and (future) credentials stay in the private `NerConfig` / `LlmConfig`. Owned rather than borrowing from the engine so callers can carry the value past the borrow that produced it. Cloning is cheap: [`HipStr`] shares the backing string via an `Arc` header. type: object properties: description: description: Optional human-readable description. type: string name: description: |- Recognizer name: the identifier a request's allowlist picks by. type: string provider: description: |- Provider slug. NER: `"bento"`, `"mock"`. LLM: `"openai"`, `"anthropic"`, `"gemini"`, `"ollama"`, `"mock"`. Owned so the type deserializes from a runtime buffer: a `&'static str` field would make the derive emit `Deserialize<'static>` only, which compiles against string literals but not against an owned `String` or a reader - the shapes a host actually decodes from. Borrowing a `&'static str` into a [`HipStr`] does not allocate, so engine-side construction stays free. type: string required: - name - provider ````