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 wiring a database or standing up a backend. Most are built-in HTTP endpoints under /api/_*, served from your app’s own origin; sign-in instead adds ready-made pages plus /api/me. The backing services are provisioned in your account only when the app needs them.

You do not choose infrastructure from this list. Describe the outcome — “let people upload a profile photo” or “email a receipt after checkout” — and the agent turns on the right pieces. The twenty-one available built-ins are grouped around six jobs: foundations, engagement, monetization, intelligence and media, automation and integrations, and policies and operations.

Capability	Endpoint	Backed by (in your account)
Sign-in	(sign-in pages), /api/me	private tables in the project database (D1)
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
File uploads	/api/_files, /api/_images	R2 + Cloudflare Images
Project 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
Realtime	/api/_live	a hibernating Durable Object
Calls	/api/_call	Cloudflare Realtime (WebRTC SFU)
Scheduled jobs	/api/_schedule	a Durable Object alarm
Background jobs	/api/_queue	a Cloudflare Queue, with retries
Workflows	/api/_flow	Cloudflare Workflows
API connections	/api/_connect	an outside API, with a key you paste once
Webhooks	/api/_hook	one unguessable URL an outside service calls
PDFs & images	/api/_render	Browser Rendering (headless Chrome)
Video	/api/_video	Cloudflare Stream
Push notifications	/api/_push	Web Push, signed with the project’s own VAPID key
Analytics	/api/_events	an Analytics Engine dataset
Bot protection	/api/_guard	Cloudflare Turnstile
Usage limits	/api/_meter	the project database (D1) — counted per person

Ask for outcomes

The capabilities compose. You describe the product behavior; the agent handles the combination and its dependencies:

You ask for	The agent can combine
“A paid AI assistant with a free daily allowance”	Sign-in + Data + AI + Payments + Usage limits
“A private workspace for each customer”	Sign-in + Teams + Data + Email
“A board that updates for everyone”	Sign-in + Data + Realtime + Push notifications
“Receive a lead, enrich it, then follow up tomorrow”	Webhooks + API connections + Background jobs + Workflows + Scheduled jobs
“A marketplace with seller uploads and checkout”	Sign-in + Data + File uploads + Payments + Email

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

All twenty-one are available to every app, but none is enabled merely because it appears in this catalog. The agent turns one on when you ask for a feature that needs it; the console toggle is a manual override.

For the ones that own a standing resource — Data, File uploads, Project assets, Background jobs, Calls and Bot protection — turning the switch on creates that resource in your account there and then: the database, the bucket, the queue, the realtime app or 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.

Some backing products need an account choice first: File uploads and Project assets need R2 enabled, Calls need Cloudflare Realtime, Background jobs need Workers Paid, and Video needs a Stream subscription. The console tells you before it tries to use one.

The capability switches name product surfaces, not infrastructure. Sign-in, Teams, Email, AI, Payments, Scheduled jobs, API connections, PDFs & images, Video, Push notifications and Usage limits use private tables in the same project database. Turning on the first one that needs those tables creates the D1 immediately, but it does not turn on Data: that switch controls the app-facing /api/_data record API. There is only ever one project database.

A few capabilities still want something from you once: Payments and API connections take a key you paste, Email needs you to name the subdomain it sends from, Webhooks mint a URL for you to paste into the service that will call it, and Project assets are the files you upload. Once Cloudflare is connected, AI, Teams, PDFs & images, Push notifications, Analytics and Usage limits need no separate service setup. The pieces that cannot exist before there is code to define them — the Durable Objects behind Realtime and Scheduled jobs, the workflow behind Workflows, and the inbound route behind Email — come up with the deploy that first needs them.

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.