Changelog

• Three engines, chosen with pii_engine: kev (the default) runs the Kev classifier model on Captain’s infrastructure. jev runs TypeSafe’s hosted Jev model, slightly more accurate with best-effort capacity. presidio is the legacy pattern engine for the built-in categories only. See Engines.
• New default for {"mask_pii": true}: a request with no pii_engine now masks with kev and no fallback. Before, it masked with captain-jev and fell back to Presidio. To keep that behaviour, send "pii_engine": "captain-jev".
• Ordered fallbacks for jev: pii_fallback takes an object, {"engines": [...], "retry_budget_seconds": 60}. List any of jev-openrouter, jev-ai-gateway and kev in the order to try them. Custom fields and instructions stay applied on every fallback. If every engine fails, that file fails to index and the rest of the job continues. See Fallback.
• Per-file engine report: each file in Get PII Report carries requested_engine, used_engines, fallback_used, fallback_reason, coverage, model and image_redaction.
• Earlier engine names keep working: captain-jev and captain-presidio, with the boolean pii_fallback, behave as before. See Earlier engine names.

• Know when a job finishes, without polling: Captain sends a signed HTTPS request to your endpoint when an indexing job ends. Each job sends exactly one event: job.completed, job.completed_with_errors, job.failed, job.timed_out or job.cancelled, with the job_id, file counts and a link to the full job. See Webhooks.
• One endpoint for every job: an endpoint receives events for every indexing job in the organization, from the API and from syncs, however many run at once. Match each event to the job you started with data.job_id. See Many jobs at once.
• Set up in Studio or with the API: add endpoints, send test events, read delivery logs and resend failed deliveries on the new Webhooks page in Captain Studio, or with the Endpoint management routes. The Captain MCP server adds captain_webhook_setup and captain_webhook_events.
• Reliable delivery: failed deliveries are retried for about 28 hours, and filters limit an endpoint to certain events, collections, syncs or sources. Each event’s payload is documented under Webhook events.

• Upload emails from Studio: the file picker and drag-and-drop now accept .msg and .eml files, and email is listed with the other supported formats. An uploaded email is indexed the same way as through the API: one document for the message and one per attachment, linked by email_attachment and email_reply_to relations. See Supported File Types.
• Chat answers quote their sources: an answer on Home backs its key facts with one to three quoted passages, each attributed to the file and page it came from (or the timestamp, for audio and video). This replaces the numbered markers and the source list that sat under the answer.

• Email files (.msg, .eml): an email is indexed as a text document for the message and one document per attachment, each parsed as its own type. email_attachment and email_reply_to relations link the parts and the thread in both directions, and every part carries email_* metadata for filtering by thread, sender, subject, or date. See Supported File Types.

• Mask identifiers of your own: with mask_pii: true, pii_fields takes up to 20 categories described in plain language with a tag you choose. Badge numbers, patient record numbers, bed assignments and the like are masked alongside the built-in categories, stored as <YOUR_TAG> and listed under that name in the masking report. See PII Masking.
• Say whose values count: pii_instructions takes plain-language guidance for the job (keep clinician names, mask patients and record numbers) and applies it to built-in and custom categories.
• Two engines: captain-jev is the default. Captain’s classifier engine reads every token in context and decides which values are personal data and of which kind, your categories included. It catches dates of birth, member ids, usernames and plates, and leaves version, ticket and product names alone. The previous engine remains as pii_engine: "captain-presidio". Details: Engines and fallback.
• Fallback is explicit and reported: when the captain-jev model is unreachable, pii_fallback chooses between masking with the legacy engine (default) and failing the file. Job status, Get PII Report and every report object carry engine and fallback.

• Latency over a period in one call: Get Query Latency returns exact p50, p95 and p99 for every query matching your filters, a histogram with bin edges, and the same bins per collection. This used to mean paging List Queries a hundred records at a time. Response size follows the number of bins, and windows cover up to 90 days.
• Unrecorded times are counted, not averaged in: measured and missing are reported separately, so a query with no timing stays out of the percentiles instead of counting as zero.
• Filters say when a setting was never recorded: filter by collection, environment, API version, rerank, search mode or metadata filter; each accepts unknown for queries that predate the field, and coverage reports what share recorded it.
• Find the slow ones: List Slowest Queries returns durations and identifiers that open in Get Query; List Latency Collections pages the collections active in a window. Guide: Query latency. The hosted MCP server adds captain_get_query_latency.

• Evaluate retrieval as a job: upload up to 10,000 queries with the documents each should retrieve, then Queue Evaluation runs them under one to eight named v3 query configurations side by side. The eval runs as a paced job and keeps results, questions, configurations and every answer.
• Scorecards per configuration: Get Evaluation Results returns recall at 1, 3 and 10, MRR, nDCG at 10 and latency percentiles per config, plus a result for every case under every config. Scoring is document level, like the MCP captain_eval tool.
• Billed as queries: each question under one configuration is one query at the plan’s query price. Only queries that ran count; Captain-side failures and unresolvable expected documents do not. The 201 response previews the maximum before anything runs.
• Every answer readable: each result carries a query_id, and GET /v3/evals/{eval_id}/answers/{case_id}/{config_name} returns the stored request and response for one case under one configuration.
• Case-set format, gold resolution, limits and persistence: Evaluations.

• Run an eval over MCP: the hosted MCP server adds captain_create_eval_upload, captain_run_eval and captain_get_eval_results, the three steps of the Evaluation API: upload up to 10,000 questions, queue them under one to eight named v3 query configurations, poll for scorecards. They need an API-key connection, since the Evaluation API accepts API keys only in v1.
• Retries replay instead of rerunning: captain_run_eval derives an idempotency key from the collection, upload and configurations, so a repeated call returns the original eval instead of billing a second one.
• Results sized for a conversation: captain_get_eval_results returns status, progress, per-configuration scorecards, billing and a compact row per case (hit, rank, latency, query_id, error code), paged by cursor; include_answers adds the stored request and top results for up to 20 cases. captain_eval stays for quick client-side comparisons. The hosted server is now at 70 tools.

• Batch document metadata: PATCH /v3/collections/{collection_name}/documents/metadata/batch merges custom metadata into up to 100 documents at once; PUT replaces each document’s whole object.
• Batch chunk metadata: the same two operations on chunks: PATCH and PUT /v3/collections/{collection_name}/chunks/metadata/batch.
• Batch chunk relations: PUT /v3/collections/{collection_name}/relations/batch creates or updates up to 100 relations, matched by source, target and relation_type.
• One result per item: a 200 carries succeeded, failed or unknown per item in request order; a failed item never rolls back the others.
• Envelope, partial success and limits: Batch Metadata & Relations. Over MCP: captain_batch_document_metadata, captain_batch_chunk_metadata, captain_batch_chunk_relations.

• Documents, a new page in Studio. Pick an environment, a collection and a document, and see what Captain actually indexed from it. Every chunk is listed in order with its type and its page. The text is rendered the way the parser produced it, so a heading looks like a heading and a table looks like a table. Open any chunk to see its stored text and its metadata.
• Chunks as a table. Filter by chunk type or search the loaded chunks. Markdown files have no layout types, so they get no type column. A Rendered / Raw switch shows the stored text exactly as it is.
• Figures. Every figure the parser extracted, grouped by page, each with a link to the chunk it belongs to. These are the same crops the asset URLs endpoint returns.
• Edit metadata in place. Change the custom metadata on a document or on any chunk directly from the page. Saving replaces the whole set, the same way the document and chunk metadata endpoints work, so what you see is what your queries filter on. You can delete a document here as well.
• Linked to the rest of Studio. Open a document from its row on Home. From the document, jump to the collection’s feed on Activity or to the job that indexed it. From a query in Activity, open the exact chunk it cited. Every view has its own URL, so a link to a document or a chunk survives a reload and can be shared.

• 12 new tools on the hosted MCP server, 64 in total: read a document or a single page, mint viewable URLs for figures, set or merge document metadata, list and roll back jobs, read or delete a job’s PII report, validate a parsing script, create a Google Cloud Storage sync, and dry-run a sync’s credentials before creating it.
• Every indexing tool now takes the full request: custom_metadata, mask_pii, max_files, skip_existing, overwrite_existing, transcription_language, and parsing_script. R2 takes the bucket’s jurisdiction, including us; S3 accepts a cross-account role; YouTube takes mode (transcript, audio, or video).
• Search: captain_search_v3 takes max_chunks_per_document; captain_search takes a metadata filter, semantic ratio, and rerank options, and returns query_id and chunk_id so results feed the query-history and chunk tools.
• Job status shows credits billed, per-file results with paging, YouTube fallbacks, and the PII report state. Details on MCP Server.

• Sign in to the hosted MCP server: add https://mcp.captain.dev/mcp to Claude Code, Cursor, VS Code or any client with remote MCP sign-in; a browser opens on Captain’s approval page to pick the organization, the environments and whether the connection may write.
• One connection, every environment: every tool takes an optional environment (development, staging or production), so one session can search development and production without reconnecting.
• Client configs for Claude Code, Codex, Cursor, VS Code, Devin and others: MCP Server.

• Edge routing for api.captain.dev: requests now connect at an edge location near the caller and travel a private backbone to Captain, so connection handshakes no longer cross the public internet. Nothing changes in your integration.
• Most agent integrations open a fresh connection for each query, and that handshake is where the time went. Median v3 Query time on a fresh connection, 100 samples per city:

• Index and sync US-jurisdiction R2 buckets: jurisdiction on the R2 indexing and R2 sync requests now accepts us alongside default (global), eu, and fedramp. Jurisdiction-restricted buckets are only visible through their jurisdiction’s endpoint, so a US-restricted bucket previously could not be reached at all; pass "jurisdiction": "us" and Captain talks to https://<account_id>.us.r2.cloudflarestorage.com. The cloud storage guide lists all four options.

• Cap one document’s share of the ranked list: max_chunks_per_document on the v3 Query request stops a single long file from occupying every result slot. Surplus chunks drop and the page backfills with the next best chunks from other documents; ranking is unchanged, only the page composition is.

Same day: Studio Improvements, Terminal Job Stages

• Indexing options on Home: a popover next to the Advanced / Basic choice sets Mask PII (mask_pii), skip or overwrite existing files (skip_existing / overwrite_existing), tags (custom_metadata, with reserved and $-prefixed keys rejected as you type), and the spoken language for audio and video (transcription_language). Remember for this collection keeps the processing type, Mask PII, and skip/overwrite choice as the collection’s defaults, and Google Drive, SharePoint, and Dropbox continuous syncs re-index with them. New source tiles cover URLs, YouTube (transcript, audio, or video mode plus on_missing_transcript), and S3, GCS, Azure Blob, R2, Supabase, and Backblaze, all without an API key in the browser.
• Search settings in the chat: results per collection, rerank on/off with the model (voyage-rerank-2.5, voyage-rerank-3, gemini-2.5-flash, gemini-3.8-flash) and candidate limit, the keyword ↔ semantic balance (semantic_ratio), skipped chunk types, archived documents, and a metadata filter, remembered per organization in the browser. The view code panel now shows the v3 Query request the settings produce, next to the v2 answer mode, with a parameter table.
• Playground covers every public endpoint: v3 Query with semantic_ratio, rerank Off / On / Custom, exclude_chunk_types, boost, all include keys, and relations; v2 Query; query history list and get (by query_id or request_id); multipart file upload; parsing script validation; document page, asset URLs, and metadata; Azure Blob sync create and a credentials check; job PII report get and delete; feedback. Query cards render a ranked results view with total, server time, rerank model, and query_id, and every card exports cURL, Python, and TypeScript.
• Sync Manager: Azure Blob Storage as a provider (container, account_name, account_key, with Event Grid guidance in the Webhook dialog), tags on create, Rotate secret for webhooks (rotate_secret), and an Environment choice on the create form. Syncs stay organization-wide; the choice picks the target collection’s environment, and an API key must exist there (412 otherwise).
• Activity: Cancel job for running or queued jobs (DELETE /v2/jobs/{job_id}) and Roll back for finished ones (PATCH /v2/jobs/{job_id}/rollback); a PII masking row with the report state and the GET /v2/jobs/{job_id}/pii call; file rows that expand to URI, document id, status, stage, error, and update time.
• API Keys and usage: renaming a key persists, Rotate key reveals the new secret once and retires the old one immediately, and the sidebar usage figure sums the current billing period from the same source as the Usage page.
• Faster chunk and document reads: GET /v3/collections/{collection_name}/chunks and GET /v3/collections/{collection_name}/documents/{document_id} no longer transfer each chunk’s stored embedding from the index before dropping it. A 100-chunk page went from about 3 s to under a second, and a 317-chunk document from 9 s to under half a second, with the same response bodies. The same routes back the Playground’s document and chunk cards and the MCP captain_list_chunks tool.

• Jobs report a terminal stage: a finished job’s progress.current_stage now ends at completed, failed, or cancelled instead of sitting on finalizing forever, and per-file stage values end at completed (indexed or skipped; the file’s status carries which) or failed. A job whose files all failed now says Job failed rather than Job completed.

• Azure Blob Storage joins the sync providers: POST /v2/collections/{collection_name}/sync/azure keeps an Azure container synced with a collection. Authenticate with the storage account’s name and access key (container + account_name + account_key; the key is stored securely, never returned, and rotates in place via PATCH /v2/syncs/{sync_id} with an account_key field). Reconciliation defaults to a 60-minute cadence, and real-time events arrive through an Event Grid subscription: one click with the Deploy to Azure template, or one az eventgrid event-subscription create: the setup guide shows both. The template is self-verifying: the deployment only goes green when Event Grid proves delivery to Captain and Captain confirms the webhook enrollment.

• Your query history, from the API: GET /v2/queries lists the queries your keys and agents have run, newest first, scoped to the calling key’s environment, with collection, status, from/to and sort filters and cursor paging. GET /v2/queries/{query_id} returns one query with its request body, response body and the retrieved chunks in one normalised shape across v2 and v3. Add include=results,request,response to the list to get feed and previews in one request; the body fields are always present and null unless requested. Bodies are archived 90 days after the query (body_status: archived); summaries are kept.
• Query responses now carry query_id: every POST .../query response (v2 and v3) returns the id of its history row, so you can fetch it back with GET /v2/queries/{query_id} straight away. The request_id a query response returns is accepted on that endpoint too.

• Two new reranker options: rerank.model on v3 Query and v2 Query now accepts voyage-rerank-3 (alias rerank-3) and gemini-3.8-flash alongside the existing voyage-rerank-2.5 (default) and gemini-2.5-flash. Voyage models are fast cross-encoders; the Gemini models are LLM rerankers with a higher quality ceiling on complex queries at higher latency — pair them with small candidate pools. The family aliases voyage and gemini keep resolving to each family’s default, so existing requests are unchanged, and the response’s rerank envelope keeps reporting the model that actually ran.