Overview

Every app Typillar builds runs on Cloudflare — your Cloudflare account. That means it can reach for a focused, opinionated set of product capabilities without you signing up for anything, wiring a database, or standing up a backend. Each one is a built-in HTTP endpoint under /api/_*, served from your app’s own origin, and backed by a Cloudflare primitive provisioned in your account.

There are twenty-one:

Capability	Endpoint	Backed by (in your account)
Sign-in	(sign-in pages), /api/me	the project database (D1) — sign-in needs Data
Teams	/api/_team	the project database (D1) — Teams needs Sign-in
Data	/api/_data	SQLite (D1), one database per project — plus Vectorize when a collection ranks by meaning
Files & images	/api/_files, /api/_images	R2 + Cloudflare Images
Assets	/api/_assets	R2 (your own files)
Email	/api/_email + inbox	Email Sending + Email Routing
AI	/api/_ai	Workers AI
Payments	/api/_pay	your own Stripe account
Live	/api/_live	a hibernating Durable Object
Calls	/api/_call	Cloudflare Realtime (WebRTC SFU)
Scheduled	/api/_schedule	a Durable Object alarm
Queue	/api/_queue	a Cloudflare Queue, with retries
Flow	/api/_flow	Cloudflare Workflows
Connect	/api/_connect	an outside API, with a key you paste once
Hooks	/api/_hook	one unguessable URL an outside service calls
Render	/api/_render	Browser Rendering (headless Chrome)
Video	/api/_video	Cloudflare Stream
Push	/api/_push	Web Push, signed with the project’s own VAPID key
Events	/api/_events	an Analytics Engine dataset
Bot check	/api/_guard	Cloudflare Turnstile
Meter	/api/_meter	the project database (D1) — counted per person

You build by talking

You will rarely write these calls by hand. You describe what you want — “let people upload a profile photo,” “email a receipt after checkout,” “make the board update live” — and the agent wires your app’s front-end to the right endpoint. These pages are the reference for what exists: so you know what your project can do, and can read the agent’s work with confidence.

That the surface is a small, typed, closed contract is not incidental — it is why the agent is reliable. It builds against twenty-one well-defined capabilities, not an open-ended backend it has to reinvent (and mis-remember) every time. Each one is defined once, in code: the route table on this site and the reference the build agent reads are generated from the same manifest, so neither can drift from what your app actually serves.

How they turn on

Each capability is off until it’s turned on — the agent turns one on when you ask for a feature that needs it (a console toggle is there as a manual override).

For the ones that own a standing resource — Data, Files, Assets, Queue, Calls and Bot check — turning the switch on creates that resource in your account there and then: the database, the bucket, the queue, the realtime app, the Turnstile widget is real before the switch settles. (Data’s vector index is the one exception: no switch creates it, a collection asking to rank by meaning does, on the next ship.) If it can’t be created — R2 isn’t subscribed on your account, say — the capability stays off and tells you why, rather than leaving you with a switch that lies.

The rest own no standing resource. A few still want something from you once: Payments and Connect take a key you paste, Email needs you to name the subdomain it sends from, Hooks mints a URL for you to paste into the service that will call it, and Assets is the files you upload. AI, Teams, Render, Video, Push, Events and Meter need nothing set up at all. And the pieces that cannot exist before there is code to define them — the Durable Objects behind Live and Scheduled, the workflow behind Flow, the inbound route behind Email — come up with the deploy that first needs them. Sign-in is the one to watch — it keeps no store of its own but runs on Data’s database, so turning Sign-in on turns Data on with it and that D1 is created immediately, just like the group above. There is only ever one project database.

Nothing is shared with Typillar or with another customer’s app. Dropping a ticket branch never touches the data — each project has one data plane that every deploy shares (see what you own).

Two rules that hold everywhere

Per-user isolation. When Sign-in is on, every capability partitions by the signed-in user automatically: one user’s files, search index — and records, unless a collection declares a wider scope (shared or public) — are invisible to another. A signed-out visitor reaches nothing at all unless a collection opts them in with anonymous, so an app without sign-in is closed by default rather than open by default. You never write the partitioning logic; it is enforced in the endpoint. The one account that sees across the partitions is a staff user, which only you can appoint.

Cost guards where you pay. AI and search spend real inference budget in your account on every call, so they carry two guards: a curated model allowlist (a caller can’t invoke an arbitrary, expensive model) and, when sign-in is on, a signed-in-user requirement (an anonymous visitor can’t run up your bill). Payments is the deliberate exception — anyone should be able to pay you — so it’s open, and the buyer is stamped when known.

Not on the list

The set is deliberately small. It covers what most projects actually need — store data, hold files, serve your own assets, sign users in, send and receive email, run AI, search by meaning, take payments, meter what you give away free, go realtime, put people on a call, run on a schedule, queue the slow work, carry a process over days, render a PDF, host video, count what happens — and stops there. When something you ask for falls outside it, the agent still builds it as ordinary application code in your app’s server; these twenty-one are simply the parts you never have to think about.