Serverless and edge: one Runtime API call before the query runs

What it protects

The same rules as at the proxy, evaluated on every statement the function sends. In a handler, the ones that most often fire:

• VERICTO-001 and VERICTO-042: DELETE and UPDATE without WHERE, for example when an optional filter arrives empty and the query builder drops it.
• VERICTO-090: tautologies such as OR 1=1, the typical pattern of a SQL injection in a public API.
• VERICTO-010 and VERICTO-011: DROP TABLE and TRUNCATE from a function that should never run them.
• VERICTO-087 (Team and Enterprise): an allowlist of tables and columns per API key. Use one key per function or group of functions: the API returns the decision and your code honours it.
• VERICTO-085 (Team and Enterprise): with columns tagged mask, the 200 answer carries rewritten_query. Run that query instead of the original: the API cannot force you to, only the TCP proxy enforces masking.

Latency and availability

Each statement adds one HTTPS call to api.vericto.com before it runs. We do not publish a figure for that round trip yet: measure it from the region or point of presence where your function runs. The shared control plane runs in AWS us-east-1, so a function far from that region pays a longer round trip.

To avoid paying the TLS handshake on every invocation, create the HTTP client outside the handler and reuse the connection. The API has a safety limit of 100 requests per second per API key; if your concurrency goes beyond it, ask us to raise it.

Connection poolers. Functions open many short connections, which is why a pooler usually sits in front of the database, such as RDS Proxy on AWS or Hyperdrive on Cloudflare. Vericto does not integrate with them or replace them: the call happens in your function, before it uses the connection, whatever the pooler.

The Runtime API, the Validation API and MCP run in Vericto Cloud, with a 99.5% SLA on Builder and 99.9% on Team and Enterprise (99.95% and 99.99% with a dedicated deployment). Service status is on the status page.

How to implement it

1. Register the database with its dialect (PostgreSQL, MySQL, Oracle, SQL Server, Snowflake or SQLite, for example D1) and copy its Database ID: integration guide.
2. Create an API key with the Runtime API scope (proxy:evaluate) and store it as a secret: on Lambda, in Secrets Manager or an encrypted environment variable; on Workers, with wrangler secret put.
3. Where the function runs SQL, first send the statement to POST /api/v1/proxy/query with query, database_id and dialect, and with an explicit timeout.
4. Run the statement only on a 200, using rewritten_query when it comes. On a 403, return an error with the rule_code. On a timeout, a network error or a 429, apply the policy you chose: fail-closed or fail-open.
5. Start in observe mode: check in the dashboard what would have been blocked, then enforce the rules.
6. Check the migrations before deploy too, with the CLI: see CI/CD and migrations.

When not to use this option

• Functions inside a VPC, next to Postgres or MySQL. Deploy the TCP proxy as a service in that VPC (ECS or Kubernetes) and point the function's connection at it: it enforces the rules without changing the code. See web application.
• A proxy for Cloudflare D1 or another SQLite database. There is none: SQLite is evaluated with the Runtime API (dialect: sqlite), the Validation API, the CLI and MCP, which is exactly this page's path.
• Batches of SQL that do not run, such as a migration file: that is the Validation API, with batches of up to 500 statements.
• You cannot change the function's code. The Runtime API needs that call; without it, only the TCP proxy evaluates the SQL.

Plan availability

Prices and every limit on Pricing.

Other architectures

• All reference architectures
• Web application
• Microservices and Kubernetes
• AI agents and text-to-SQL
• Data warehouse and analytics
• Data pipelines
• CI/CD and migrations
• Multi-tenant SaaS
• Enterprise and regulated