What is the difference between a read-only and a read-write API key in Qdrant, and when would you issue each?

Qdrant supports two standard API key types. The read-write key (configured as api_key) grants full access to all operations: creating and deleting collections, inserting, updating, and deleting points, performing searches, creating snapshots, modifying cluster configuration, and all administrative operations[reference:9]. The read-only key (configured as read_only_api_key) is restricted to read operations: listing collections and viewing collection info, retrieving points by ID, performing vector searches, scrolling through points, and viewing cluster information[reference:10]. It cannot create or delete collections, insert, update, or delete points, create indexes, create snapshots, or modify cluster configuration[reference:11]. The distinction is about write capability, not about data visibility - a read-only key can query any collection it can reach.

The operational value of the read-only key is least-privilege access for query-only services. In a typical RAG pipeline, the embedding and indexing service needs a read-write key to upsert vectors, while the query service that serves user requests only needs to search. Issuing a read-only key to the query service means that a compromise of that service - through a dependency vulnerability, a leaked environment variable, or a misconfigured container - cannot destroy data or exfiltrate it by writing it somewhere else. The official documentation recommends using read-only keys for client-facing applications to prevent accidental or malicious data modifications[reference:12]. The read-only key is configured separately from the read-write key and uses the same header mechanism, so the client code does not need to change beyond the key value. A service using the read-only key can still perform every read operation it needs: search, scroll, retrieve by ID, and inspect collection metadata.