Overview
Endpoints allow you to create custom API interfaces with secure, controlled access. You can define three types of endpoints:
- Query Endpoints - Execute SQL queries on your datasets with dynamic filters
- Action Endpoints - Execute serverless Python functions for custom logic
- Vector Endpoints - Perform semantic similarity search on vectorized data
Creating Endpoints
- Navigate to your Project
- Create a new YAML file for your endpoint (e.g.,
api-orders.yaml)
- Define your endpoint configuration
- Reference it in your
config.yaml file
Endpoint Types
Although the YAML syntax uses an endpoints: array, only one endpoint definition per file is supported. Defining multiple entries in a single file will result in an error. Use a separate YAML file for each endpoint and register each file individually in config.yaml.
Query-Based Endpoints
Query endpoints execute SQL queries on your data with dynamic filtering using Jinja templating.
Example YAML Configuration:
Action-Based Endpoints
Action endpoints execute serverless Python functions when called. Perfect for sending notifications, processing data, calling external APIs, or automating workflows.
Example YAML Configuration:
The action_id references an action function in your project. Get the ID from your action details page.
The action function must return a list. Returning any other type raises ActionEndpointResultMustBeListError.
Vector-Based Endpoints
Vector endpoints enable semantic similarity search on your vectorized data via HTTP API. Perfect for building search features, recommendation systems, or RAG applications.
Example YAML Configuration:
The vector_id references a Vector in your project. Get the ID from your vector details page.
Register in config.yaml
Reference your endpoint file in config.yaml:
Configuration Reference
Common Attributes
| Attribute | Type | Required | Description |
|---|
name | string | Yes | Unique endpoint identifier |
type | string | Yes | Endpoint type: query, action, or vector |
config | object | Yes | Type-specific configuration |
Query Config Attributes
| Attribute | Type | Required | Description |
|---|
query | string | Yes | SQL query with Jinja templating |
filters | array | No | List of filter parameters |
Action Config Attributes
| Attribute | Type | Required | Description |
|---|
action_id | string | Yes | Action function ID to execute |
Vector Config Attributes
| Attribute | Type | Required | Description |
|---|
vector_id | string | Yes | Vector ID for similarity search |
Filter Configuration
Filters are only for query endpoints and define dynamic parameters:
| Attribute | Type | Required | Description |
|---|
name | string | Yes | Filter parameter name (alphanumeric, -, _) |
type | string | Yes | Data type (see types below) |
optional | boolean | No | Whether filter is optional (default: true) |
Filter Types
| Type | Description | Example Usage |
|---|
string | Text parameter | country, category |
integer | Numeric parameter | year, limit |
float | Decimal parameter | price, rating |
date | Date parameter | start_date, end_date |
datetime | DateTime parameter | created_at, updated_at |
boolean | Boolean parameter | active, is_featured |
enum | Enumeration parameter | status, priority |
Using Endpoints
Endpoints are accessible via HTTP requests. Query and vector endpoints use GET requests, while action endpoints may vary based on implementation:
Query Endpoint Response
Query endpoints return JSON data with query results:
Action Endpoint Response
Action endpoints return the list your Python function returns:
Your action function must return a list. Returning any other type (dict, string, None, etc.) raises ActionEndpointResultMustBeListError. Always wrap your result in a list, even when there is only one item.
Vector Endpoint Response
Vector endpoints return semantically similar results based on your search query:
Using Vector Endpoints:
Query Parameters for Vector Endpoints:
| Parameter | Type | Required | Description |
|---|
query | string | Yes | Search query in natural language |
Authentication
Endpoints use API key authentication via the x-api-key header:
Error Responses
| Status Code | Description |
|---|
| 200 | Success |
| 400 | Bad Request - Invalid parameters |
| 401 | Unauthorized - Invalid API key |
| 403 | Forbidden - Access denied |
| 404 | Not Found - Endpoint doesn’t exist |
| 500 | Internal Server Error |
Example error response:
Advanced Query Features
Jinja Templating
Endpoints support Jinja templating for dynamic queries:
Caching
Endpoint responses can be cached:
- Default cache TTL: 60 minutes
- Cache headers indicate freshness
- Use cache-busting parameters when needed