API Reference

Astro exposes several public API families to application authors: the render context available as the Astro global and endpoint context, virtual modules such as astro:assets, add-on packages such as @astrojs/rss, and integration or adapter surfaces that participate in build and deployment. This page is a reference-oriented map rather than a tutorial. It explains how the public documentation vocabulary connects to the repository evidence supplied for this page, with special attention to the asset/font build helpers and package build contracts visible in the source set.

The official API reference describes the render context as the runtime object available during page, endpoint, and middleware rendering. The official assets reference describes imports from astro:assets, including Image, Picture, Font, getImage, inferRemoteSize, getConfiguredImageService, imageConfig, fontData, and experimental_getFontFileURL. The repository snippets here do not include those public export declarations directly, but they do show supporting implementation for font URL generation and package publication boundaries. Read the public API names as the author-facing contract, and the source-backed sections below as the implementation and build signals available from this slice of the repository.

Purpose and Scope

Use this page when you need to understand which API concepts belong together and what source-level contracts are visible behind them. In an Astro project, page authors interact with .astro component APIs, route authors interact with context objects and endpoint functions, content authors may add RSS generation, and asset authors import image or font helpers from virtual modules. Those public entry points intentionally hide much of the build pipeline, but the hidden pipeline still has concrete responsibilities: stable output paths, cacheable package builds, correct content security policy resources, and observable failures during prerendering.

The supplied implementation files focus on font assets during build. A font asset starts as an original URL and content type, then becomes a generated file identifier and a URL suitable for emitted HTML or CSS. That flow is important for the public astro:assets surface because a component such as Font or an image helper can only be reliable if build-time asset identifiers are deterministic and URLs are compatible with base, assets prefixes, and adapter-added query parameters. Sources: packages/astro/src/assets/fonts/infra/build-font-file-id-generator.ts, packages/astro/src/assets/fonts/infra/build-url-resolver.ts

The supplied configuration files show how Astro workspace packages are compiled for distribution. The shared TypeScript build config establishes a source-to-dist convention, while package-specific configs either inherit it directly or extend it with additional declaration inputs. This matters for API reference readers because published packages such as @astrojs/rss and astro-prism need repeatable build boundaries before their documented imports can be consumed by applications. Sources: configs/tsconfig.build.json, packages/astro-prism/tsconfig.build.json, packages/astro-rss/tsconfig.build.json

Relevant Source Files

• .changeset/sharp-bags-build.md — records a patch-level adapter behavior fix where prerendering errors in workerd are buffered and surfaced as build failures instead of being silently swallowed.
• configs/tsconfig.build.json — defines the shared package build contract with rootDir, outDir, tsBuildInfoFile, and include defaults for source packages.
• packages/astro-prism/tsconfig.build.json — extends the shared build config and includes both ./src and ./virtual.d.ts, signaling that virtual module declarations are part of this package build.
• packages/astro-rss/tsconfig.build.json — extends the shared build config directly, matching the simple compiled-package pattern used by the RSS package.
• packages/astro/src/assets/fonts/infra/build-font-file-id-generator.ts — implements BuildFontFileIdGenerator, which converts font content and type into a hashed file identifier.
• packages/astro/src/assets/fonts/infra/build-url-resolver.ts — implements BuildUrlResolver, which converts emitted asset identifiers into build URLs while tracking CSP resources and generated URLs.

Public API Families

The render context is the central runtime API family. In .astro components it appears as the Astro global, and in endpoint functions or middleware it is passed as a context object. Official docs describe properties such as props and methods such as redirects as part of the current render. That design lets the same route-aware data model serve static generation, server endpoints, and middleware. Some properties are meaningful only for on-demand rendering, so API users should treat the context as request-sensitive instead of assuming every property behaves identically during prerendering.

The assets API family is the relevant public surface for the source-backed implementation details on this page. Official docs show that authors import Image, Picture, Font, getImage, inferRemoteSize, and configuration helpers from astro:assets. The repository code here supports that surface by resolving build URLs for font files and generating identifiers from font content. The public contract is ergonomic and component-oriented, while the implementation contract is deterministic and adapter-aware: emitted URLs must respect base paths, optional assets prefixes, query parameters, and CSP collection. Sources: packages/astro/src/assets/fonts/infra/build-font-file-id-generator.ts, packages/astro/src/assets/fonts/infra/build-url-resolver.ts

Content and feed APIs form another documented family. The official tutorial sequence introduces import.meta.glob() for reading files, getStaticPaths() for route generation, and the Astro RSS package for generating feeds. In the supplied repository evidence, packages/astro-rss/tsconfig.build.json shows that @astrojs/rss follows the shared compiled package convention. That does not document the feed function signature by itself, but it does show that the package participates in the workspace’s standard TypeScript build pipeline before publication. Sources: packages/astro-rss/tsconfig.build.json, configs/tsconfig.build.json

Compact Reference

Area	Concrete names visible here	Contract
Shared package build	rootDir, outDir, tsBuildInfoFile, include	Compile package source from ${configDir}/src to ${configDir}/dist and store TypeScript incremental build info under dist/._cache/ts_build/build.tsbuildinfo.
Prism package build	extends, include	Reuse the shared build config and include ./src plus ./virtual.d.ts, preserving virtual module typing in the package build.
RSS package build	extends	Reuse the shared build config without package-local overrides in the provided evidence.
Font file IDs	BuildFontFileIdGenerator, generate({ originalUrl, type })	Resolve original font content, hash it, and append the font type extension to produce a build file identifier.
Font URLs	BuildUrlResolver, resolve(id), cspResources, urls	Resolve emitted asset IDs into URL strings, track CSP resource origins, and retain the generated URL list.
Adapter prerendering signal	Cloudflare workerd patch changeset	Buffer response bodies during prerendering so thrown rendering errors fail astro build instead of producing truncated HTML.

BuildFontFileIdGenerator has a deliberately small contract. Its constructor receives a hasher and a contentResolver, both typed through the font infrastructure definitions. Its generate() method accepts an originalUrl and a FontType, resolves the original content, hashes that content string, and returns a filename-like identifier in the form hash.type. The important API behavior is not the private class name; it is the deterministic relationship between font content and build output. If the same font content is resolved, the generated identifier remains stable for caching and output references. Sources: packages/astro/src/assets/fonts/infra/build-font-file-id-generator.ts

BuildUrlResolver is the more environment-sensitive helper. Its constructor accepts base, assetsPrefix, and searchParams. During resolve(id), it chooses an assets prefix when one is configured for the file extension; otherwise it uses a same-origin path with a leading slash. It then creates a placeholder URL, copies configured search parameters into it, stringifies the result, and stores both the resulting URL and the CSP resource needed for that URL. This is the source-level bridge between an emitted asset identifier and the URL an Astro build can safely reference. Sources: packages/astro/src/assets/fonts/infra/build-url-resolver.ts

System-to-Code Mapping

The path from public API to generated output can be read in layers. At the authoring layer, code imports from documented modules such as astro:assets or uses the Astro render context. At the package layer, TypeScript build configs ensure that packages and declarations are emitted from predictable source roots into distribution directories. At the asset layer, helpers generate content-addressed font file IDs and route those IDs through base paths, asset prefixes, and query parameters. Each layer protects a different part of the public promise: usable imports, installable packages, and correct runtime URLs. Sources: configs/tsconfig.build.json, packages/astro/src/assets/fonts/infra/build-font-file-id-generator.ts, packages/astro/src/assets/fonts/infra/build-url-resolver.ts

The astro-prism build config is a useful example of an API package carrying type information beyond ordinary source files. Its inclusion of ./virtual.d.ts signals that virtual module declarations are part of the package’s build inputs. That pattern is relevant to Astro APIs because many documented surfaces are virtual imports rather than physical source files in an application. A reference reader should therefore look not only for runtime implementation files, but also for declaration files that make editor and TypeScript usage possible. Sources: packages/astro-prism/tsconfig.build.json, configs/tsconfig.build.json

The changeset adds an operational API signal for server-side and adapter-backed rendering. It describes a Cloudflare workerd fix where prerender response bodies are fully buffered before being returned to the build process, ensuring thrown rendering errors become visible build failures. While not a public function signature, this is a public behavior guarantee: astro build should not succeed with truncated HTML when a prerendered page throws during rendering. For API consumers, that reinforces that route and adapter behavior is part of the observable contract. Sources: .changeset/sharp-bags-build.md

Usage Guidance and Next Steps

When using the render context, write route code with the current render mode in mind. Static pages, prerendered routes, live server endpoints, and middleware can share the context shape but differ in what information is available and when side effects happen. When using assets APIs, prefer the documented virtual module imports and let Astro produce final URLs instead of constructing _astro paths manually. The implementation here shows why: output URLs may include a configured base path, per-extension assets prefix, and adapter-level query parameters, all of which are easy to lose in handwritten paths.

When maintaining API packages in this repository, keep the shared build contract in mind. A package that only needs compiled source can inherit configs/tsconfig.build.json directly, as shown by @astrojs/rss. A package that exposes virtual declarations must include those declarations explicitly, as shown by astro-prism. When changing build-time asset behavior, check whether the change affects CSP resources, generated URL lists, or adapter-added tracking parameters, because those details can surface through documented APIs even when the helper class itself remains internal. Sources: configs/tsconfig.build.json, packages/astro-prism/tsconfig.build.json, packages/astro-rss/tsconfig.build.json, packages/astro/src/assets/fonts/infra/build-url-resolver.ts

Next, read the module-specific reference pages for the public signatures: astro:assets for image and font helpers, @astrojs/rss for feed generation, and the render context reference for Astro and endpoint context properties. If you are investigating implementation behavior, start from the asset helper classes on this page, then follow the package that exports the documented virtual module. If you are validating deployment behavior, include adapter changesets in your review because they capture observable build and prerendering guarantees.