What is built: Built-in services

The errors this page describes are built with the feature they belong to.

Feature	Status
Email	Built: email's templates, the shared layout, `email:`, sending after commit through the SMTP driver, attachments and parking (Email rules: templates and sending). The SMTP conversation runs in the driver, over the host's transport and its TLS upgrade.
Jadpo's own magic-link email	Built: at all five levels, worded by Jadpo or reworded by the app, wrapped in the app's layout, the app's own email filled with the link and the code, or the app's own sending given them (Jadpo's own magic-link email, Your own magic-link email).
The privacy emails	Not built yet. They come with data requests (Data requests).
Mail packages	Built: a mail package as the connection, partials and `email.sent` (Mail packages, partials and `email.sent`).
The dev inbox and the health score	Partly built: the dev inbox, `jadpo email`, the health score, `email.health_problem` and `jadpo email check-domain` (The dev inbox and the health score), with SpamAssassin's rules in the score (SpamAssassin in the health score). Not built yet: the inbox page as part of the developer console, and its link to each mail's trace, which comes with `jadpo trace`.
Rate limits	Partly built: default rate limits with routes, a route's and an API's own `rate_limit:`, and their store on Workers, Cloudflare's rate-limiting binding (Rate limits on Workers). Not built yet: Redis's driver, which comes with caches. Until then a deployable whose store is Redis counts in its own memory, which on Workers is the judgement call `rate_limits.counted_in_memory`. Not built: turning a limit off, which the design notes say needs an acceptance and which has no syntax yet; `requests:` and `within:` can only loosen it. A generated route's own limits don't appear in OpenAPI's `x-jadpo-rate-limit` or `jadpo routes`, and a magic-link refusal gives `Retry-After` without the `RateLimit` headers. The binding's windows, the Wrangler entries and what its documentation says of locations and accuracy aren't yet checked against the real edge.
Outside calls	Built: the one place in the runtime every capability's calls go through, with a delivery that hands its event to a capability, parked as `outcome_unknown` when a send without a key may have acted (How every outside call is made safe).
Files	Partly built. Built: the `files` capability's first part, its calls made the same way: `Driver.disk` connections, `File` fields, `store.put`, `store.read` with its whole-read cap and its two errors, the disk driver `jadpo dev` keeps files with and the in-memory store a test's are in, which the file helpers' reads walk (Data formats; File fields, `put`, `read` and the disk driver); every write of a `File` field holding the file to the field's `store:`, `types:` and `max_size:` (What a write checks); the pieces the file helpers' writes put, joined into one file or dropped by the store (How an export writes its file); and a gzip file unpacked as the file helpers read it, up to `max_unpacked_size:` (Reading gzip). A native deployable's disk driver keeps each store at its `path:`, made the app's user's alone as it starts, a root other users can write to not built, and a write below `free_space_floor:` answering `storage_full`, in `jadpo dev` too; `jadpo check` refuses a `path:` that is relative or inside the project (`connection.disk_path_invalid`); and the manifest lists the disk stores that keep a deployable on one server (The disk driver). A file's bytes are deleted once no record holds it, after the change commits, through the generated subscriber `files <store>`, and a day after a `put` when no record ever held them, a person's erasure and retention included (Deleting and erasing). The floor is a monitoring threshold (Monitoring). Not built yet: upload slots, multipart ones included, downloads, fields naming one store of files in entities of two databases, the S3 driver, `fixture_file` and telling the store to fail from a test, and image variants and scanning when an app needs them, the application's `scanning:` being `toolchain.not_built_yet` where it is written; and the `jadpo files` commands (`ls`, `show`, `get`, `put` and `copy`).
Flags	Partly built: `flags { }` of `Bool` and enum flags with their `default:`, `owner:` and `expires:`; `flags.<name>` in actions, tests and a route's `run:` arguments, worked out for the caller from `jadpo_flags` in `flags: { store: }`, held in each server's memory and fixed for the operation; a test's `flags:`; `flag.unknown`, `flag.read_context` and `flag.expired` (Flag rules: declaring, reading, testing). `jadpo flags list`, `set`, `reset` and `remove`, each change logged in `jadpo_flag_changes`; `flag.value_untested`; and `client: true` with each API's `GET /flags` (Flag rules: changing, listing, removing). Not built yet: named tenants, which wait for tenancy to be settled for flags; and a user's erasure reaching their `id` in `jadpo_flags` and `jadpo_flag_changes`, which comes with erasures.
Audit	Partly built: an entity's `audit:`, an entry in the same transaction as each change, `history` with the record's `read` grant and the fields the caller can read, retention by the purge schedule, entries deleted with their record by erasure, `AuditEntryRecorded` to subscribers, and the permissions report's line (Audit trail). Not built yet: what What the audit trail doesn't keep yet lists, each `toolchain.not_built_yet` where it is written, and `publishing`, which comes with outgoing webhooks.
Search	Partly built: on PostgreSQL, `search: { fields: language: }` with its generated column, GIN index and migrations, `matches` with a `SearchText`, the best matches first in keyset pages, and policy over every search (Search). Not built yet: an engine's `store:`, `toolchain.not_built_yet` where it is written, and `jadpo search reindex`, which come with the `search` capability's packages; and searching a field of a sensitive category, `toolchain.not_built_yet` in `fields:` until the access records are built.
Documents	Not built yet: the application's `documents:` is `toolchain.not_built_yet` where it is written.
Bot protection	Not built yet: the application's `bot_check:` and a route's are `toolchain.not_built_yet` where they are written.
Outgoing webhooks	Not built yet.
The `telemetry:` section	Not built yet: it is `toolchain.not_built_yet` where it is written. Nor is telemetry in the developer console, or `jadpo traces`, `jadpo metrics` and `jadpo logs`, which read it in development.
Path IDs	Not built yet for requests. Each body's ways are numbered, and the gate compares the paths each test's bodies took when it runs them interpreted and compiled, but no request carries a `path` or a `path_key`, and `jadpo path` isn't built.
Monitoring thresholds	Partly built: `thresholds { }` in each domain's `monitoring.jadpo`, each threshold checked to watch a route, action, query, schedule or subscriber of its domain with limits that apply to it; the per-request limits in the runtime's plan, the across-request limits and the disk floors written to `build/monitoring/` as Prometheus and OpenSLO rules and carried in the manifest; and a limit raised or removed, or a floor lowered, refused by `check` until a `ThresholdChange` acceptance names it (What Jadpo generates from thresholds). Not built yet: acting on the per-request limits, which comes with the `telemetry:` section, starting values from the query report and production, and an agent's proposals through MCP.

Related