Skip to main content
Qdrant provides two primary API interfaces for interacting with the vector database: a REST API and a gRPC API. Both interfaces provide comprehensive access to all Qdrant features, with gRPC offering higher performance for production workloads.

​
REST API

The REST API is the easiest way to get started with Qdrant. It provides a simple HTTP interface with JSON payloads, making it compatible with any programming language or tool that can make HTTP requests.

​
Base URL

By default, the REST API is available at: 
http://localhost:6333
The base URL format is: 
{protocol}://{hostname}:{port}
Where:
  • protocol: http (default) or https (when TLS is enabled)
  • hostname: localhost (default) or your server hostname
  • port: 6333 (default HTTP port)
For production deployments, always use HTTPS with proper authentication. See the authentication guide for details.

​
Request Format

All REST API requests use standard HTTP methods:
  • GET - Retrieve resources
  • POST - Create resources or perform searches
  • PUT - Update or insert resources
  • DELETE - Remove resources
  • PATCH - Partially update resources
Request bodies use JSON format with Content-Type: application/json header. Example request: 
curl -X POST 'http://localhost:6333/collections/my_collection/points/search' \
  -H 'Content-Type: application/json' \
  --data-raw '{
    "vector": [0.2, 0.1, 0.9, 0.7],
    "limit": 3
  }'

​
Response Format

All REST API responses return JSON with a consistent structure: 
{
  "result": { /* response data */ },
  "status": "ok",
  "time": 0.000123
}
Where:
  • result: The actual response data (varies by endpoint)
  • status: Either "ok" for success or contains error information
  • time: Request processing time in seconds
Error response: 
{
  "status": {
    "error": "Collection not found"
  },
  "time": 0.000045,
  "result": null
}

​
Query Parameters

Many endpoints support common query parameters:
  • consistency - Define read consistency guarantees (see distributed deployment)
  • timeout - Override global timeout for the request (in seconds, minimum 1)
  • wait - Wait for operation to complete before returning (true or false)
Example with query parameters: 
curl 'http://localhost:6333/collections/my_collection?timeout=30'

​
gRPC API

The gRPC API provides a high-performance alternative to REST, ideal for production workloads requiring low latency and high throughput.

​
Base URL

By default, the gRPC API is available at: 
http://localhost:6334
The gRPC port is 6334 by default. You can configure this in your config.yaml: 
service:
  grpc_port: 6334  # Set to null to disable gRPC
gRPC is optional and can be disabled by commenting out or setting grpc_port: null in the configuration.

​
Performance Benefits

gRPC offers several advantages over REST:
  • Binary protocol - More efficient than JSON for large payloads
  • HTTP/2 multiplexing - Multiple concurrent requests over a single connection
  • Streaming support - Efficient for batch operations
  • Lower latency - Reduced serialization overhead

​
Protocol Buffers

The gRPC API is defined using Protocol Buffers. You can find the .proto definitions in the Qdrant repository:

​
Using gRPC

Most Qdrant client libraries support both REST and gRPC: 
from qdrant_client import QdrantClient

# Use gRPC (recommended for production)
client = QdrantClient(
    host="localhost",
    grpc_port=6334,
    prefer_grpc=True
)

​
API Versioning

Qdrant follows semantic versioning. The API version is tied to the Qdrant version you’re running:
  • Major version changes may include breaking API changes
  • Minor version changes add new features while maintaining backward compatibility
  • Patch version changes contain bug fixes and non-breaking improvements
You can check your Qdrant version via the root endpoint: 
curl http://localhost:6333/
Response: 
{
  "title": "qdrant - vector search engine",
  "version": "1.8.0"
}
Always test your application against a new version in a staging environment before upgrading production.

​
OpenAPI Specification

Qdrant provides a complete OpenAPI 3.0 specification for the REST API: The OpenAPI specification can be used to:
  • Generate client libraries for any language
  • Import into API testing tools (Postman, Insomnia, etc.)
  • Validate request and response schemas
  • Generate documentation automatically

​
Health Check Endpoints

Qdrant provides several health check endpoints, useful for monitoring and orchestration:

​
Root Endpoint

curl http://localhost:6333/
Returns Qdrant version information.

​
Kubernetes Health Checks

Qdrant provides dedicated endpoints for Kubernetes:
  • /healthz - General health check
  • /livez - Liveness probe (checks if the service is running)
  • /readyz - Readiness probe (checks if the service can accept traffic)
Example: 
curl http://localhost:6333/readyz
Response: 
healthz check passed

Next: Authentication

Learn how to secure your Qdrant instance with API keys and TLS certificates

​
Additional Resources

Collections API

Create and manage collections

Points API

Insert, update, and delete vectors

Search API

Perform vector similarity searches

Client Libraries

Use official client SDKs