How are AutoREST routes generated and when do they change?

qail-gateway discovers tables, primary keys, and foreign-key relations at startup and generates REST routes under /api. Route shape changes when schema metadata changes.

Can I restrict RPC and query execution in production?

Yes. Gateway supports policy enforcement, query allow-lists, RPC allow-lists, signature checks, and production-strict startup checks to fail closed on unsafe config.

What is the difference between /api routes and /qail endpoints?

The /api surface is schema-driven REST (CRUD, nested, aggregate, RPC). The /qail and /qail/binary endpoints execute text DSL and binary AST payloads directly.

How does tenant context flow from JWT to PostgreSQL RLS?

Gateway validates JWT/JWKS, maps tenant/user claims into request context, and forwards that context to PostgreSQL session state so native RLS policies enforce row isolation.

QAIL Gateway: Instant REST & Realtime APIs for PostgreSQL

Gateway Capability Matrix

Capability data below is sourced from qail.rs/gateway crate routes, docs, and configuration checks. It reflects the current runtime surface for the 0.27.9 line.

Capability	Current Data	Notes
Primary positioning	QAIL Gateway AutoREST runtime for PostgreSQL	qail-gateway generates API routes from schema and executes through qail-pg.
Current crate release	0.27.9	Matches the current QAIL workspace release line.
AutoREST surface	CRUD + nested resources + aggregate + RPC	Auto-generated routes include /api/{table}, /api/{table}/:id, /api/{table}/aggregate, /api/{table}/:id/{child}, and /api/rpc/{function}.
AST query paths	/qail, /qail/binary, /qail/fast, /qail/batch	Supports text DSL and binary AST entry points, with REST alias /api/_batch.
Realtime	WebSocket + live query + event triggers	WebSocket endpoint at /ws with subscription and live-query workflows; webhook triggers supported by gateway event engine.
Security model	JWT/JWKS + RLS + policy engine + allow-lists	Tenant/user claims map into PostgreSQL session context; gateway supports policy, query allow-list, RPC allow-list, and signature checks.
DevEx endpoints	/api/_openapi, /api/_schema, /api/_schema/typescript, /api/_rpc/contracts	Auto-generated OpenAPI and typed contract endpoints for client/tooling integration.
Production strict mode	Fail-closed startup checks	When enabled, gateway validates auth, CORS strictness, admin token, allow-list config, RPC signature checks, and transport hardening.

Core Endpoint Surface

Gateway combines AutoREST, RPC, query protocol, and realtime endpoints in one service process.

Method	Path	Purpose
GET/POST	/api/{table}	AutoREST list/create from discovered schema tables
GET/PATCH/DELETE	/api/{table}/:id	Primary-key read/update/delete when table has PK
GET	/api/{table}/aggregate	Aggregation functions (count/sum/avg/min/max)
GET	/api/{table}/:id/{child}	Nested child-resource route derived from FK metadata
POST	/api/rpc/{function}	Function-as-RPC route with allow-list and signature controls
POST	/qail and /qail/binary	QAIL text DSL and AST-binary query ingestion paths
GET	/ws	WebSocket subscriptions and live query updates
GET	/api/_openapi	Auto-generated OpenAPI 3.0 contract

Operational Runtime Guards

Tenant Isolation

Gateway maps auth claims into PostgreSQL session context and relies on native RLS so tenant boundaries are enforced in database policy, not app-side filter conventions.

Policy + Query Gates

YAML policy evaluation, query allow-listing, RPC allow-listing, signature checks, and complexity/cost controls provide layered fail-closed behavior.

Production Strict

production_strict=true startup checks enforce auth and transport posture before service accepts traffic.

Quick Start (Rust)

1. Add Gateway Dependencies

Add gateway, core AST, and PostgreSQL runtime crates.

cargo add qail-gateway qail-core qail-pg

2. Build and Serve

Minimal embedded server startup path.

use qail_gateway::Gateway;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let gateway = Gateway::builder()
        .database("postgres://postgres:postgres@localhost:5432/app")
        .schema("schema.qail")
        .policy("policies.yaml")
        .bind("0.0.0.0:8080")
        .build_and_init()
        .await?;

    gateway.serve().await?;
    Ok(())
}

3. Test AutoREST and OpenAPI

Use generated endpoints immediately after startup.

curl http://localhost:8080/api/orders
curl http://localhost:8080/api/_openapi
curl http://localhost:8080/health

PostgreSQL drivers - direct Rust and Zig runtime pages.
SDK page - client layers that target the gateway surface.
Gateway docs hub - full gateway navigation and concepts.
REST API reference - filter/operator/expand details.
Auth + security reference - JWT, RLS, policy, allow-lists.
Architecture and invariants - request lifecycle and safety model.
Changelog - release timeline and dedicated page links.

PostgreSQL Drivers SDKs

FAQ

How are gateway REST routes generated?

On startup, qail-gateway inspects schema metadata and derives route surfaces for CRUD, nested resources, aggregates, and RPC under /api.

Can I lock down execution paths before production traffic?

Yes. Enable strict config and use policy rules plus query/RPC allow-lists so unsafe paths fail closed during startup and request validation.

What is the practical split between /api and /qail?

/api is resource-oriented AutoREST. /qail and /qail/binary are AST/DSL execution endpoints for teams that need direct query-shape control.

How does multi-tenant isolation work end-to-end?

JWT claims are validated and mapped to tenant/user context, then PostgreSQL native RLS policies enforce row-level isolation during execution.

Instant API Gateway for PostgreSQL