The Gateway, App, and API

The Gateway is the Airbrx product. It's where your tenant lives, where your rules execute, where the cache is built, and where the warehouse compute you would otherwise be paying for quietly disappears. The App and API are how you set it up and manage it — important, but secondary to the Gateway itself.

The Gateway — where the work happens

Each tenant gets a gateway address at <slug>.gateway.airbrx.ai. Your Tableau workbooks, Power BI reports, DBeaver sessions, dbt projects, and Python scripts connect there instead of at your warehouse. From the tool's perspective nothing else changes — same SQL dialect, same credentials, same drivers. From your bill's perspective everything changes, because most of those queries never wake the warehouse.

Inside the Gateway, four things are happening for every query:

• Your rules are applied. The Gateway evaluates the tenant's rule list against the incoming SQL and decides what to do — cache it, return a cached result, refuse to cache, mark another rule's results as stale.
• The cache is built and served. Cached results live in cloud storage, keyed deterministically from the matching rule. Hits return in milliseconds, with no warehouse compute charged.
• The cache is busted on writes. When a write matches an invalidation rule, the Gateway records a marker that flips the relevant cached results to stale immediately. Next read fetches fresh.
• Warehouse compute drops dramatically. Read-heavy BI workloads have enormous repetition baked in: the same dashboards, the same refreshes, the same exploratory queries from the same handful of users. Each cached response is a warehouse execution you didn't pay for. The savings compound quickly.

The exciting part — the part most data platforms don't have — is the combination of fine-grained cache configuration with fine-grained rule-busting. Most caching layers give you broad TTLs and leave invalidation as someone else's problem. Airbrx treats cache rules and invalidation rules as peers — same matching language, same edit surface, both authored in the App. That's what lets you write something like "cache aggregate queries on the orders table for one hour, keyed per user, but invalidate immediately when an INSERT lands on that table." See Rules as the differentiator for the model in detail.

The App — how you set things up

The App at app.airbrx.ai is where you spend your administrative time. It's a static-HTML application that runs entirely in your browser — no agent to install, no backend you operate. Everything you see is fetched from the API, and everything you change is written back to it. If you closed the browser tab right now you wouldn't lose any state.

In the App you'll:

• Sign in and pick the account and tenant you're working in
• Configure a tenant — connect it to your Databricks or Snowflake warehouse
• Author cache rules and invalidation rules in the rules workshop
• Watch live traffic and drill into individual statements to see why they did or didn't hit cache
• Invite teammates, scope their access, manage Personal Access Tokens for service flows

The App is a consumer of the API. You could drive everything through the API directly if you preferred — the App is the admin surface, not the system of record.

The API — the source of truth

The API at api.airbrx.ai stores everything that isn't traffic: accounts, users, tenants, every cache rule, every invalidation rule, every grant of access, every Personal Access Token. The Gateway reads its rule set from the API. The App reads and writes everything else through the API.

The API is also authoritative for every authorization decision. The App renders affordances based on what your token claims it can do — but the API has the final word, and 403 responses tell the App when to back off and show an upgrade prompt or scope-restriction message. JWTs and Personal Access Tokens both carry the same four-axis scope (method × path × tenant × account), so a token for a CI pipeline can be locked down to exactly the operations it needs.

The full surface lives at the API reference.

How they fit together

BI tools talk to the Gateway. Admins talk to the App in their browser. AI agents and CI pipelines talk to the API directly, with their own scoped tokens. The App talks to the API too — it's just another consumer. The Gateway pulls its rule set from the API in turn. Tenant configuration flows one way (App or Agent → API → Gateway), traffic flows the other (BI tool → Gateway → warehouse), and the two directions never interfere with each other.

AI agents are first-class API consumers, not a special case. A scoped Personal Access Token gives an agent exactly the read or write capability it needs — query the analytics API, propose new cache rules, push them to a tenant — without going through the App. The four-axis scope on every token (method × path × tenant × account) keeps that capability bounded.

Where to go next

• How the Gateway works — request lifecycle, predictable cache keys, credentials pass-through.
• Rules as the differentiator — fine-grained cache plus fine-grained rule-busting, in detail.
• Security posture — credentials, RLS, masking, audit, isolation, scopes.