TYPO3 Delivery API (Step one: content models)

TYPO3 Association Community Budget Ideas 2026 Round Two
1

by @somebdyelse

What is my idea about?

This proposal, “content models”, is the first of two steps towards a TYPO3 Delivery API.

The overall goal: TYPO3 Delivery API

The overall goal is to give TYPO3 a modern, well-documented Delivery API that allows other systems to retrieve content stored in the CMS in a reliable and structured way. This allows TYPO3 to be used as a content hub, consumed by other applications as a headless or hybrid CMS. Applications include:

  • Web apps (Nuxt, Next, …) to render modern web pages
  • Mobile applications
  • AI agents accessing content from the CMS
  • Interactive elements within a static web page
  • Search indexing
  • Server to server communication
  • Reporting tools

For many organizations, the existence of an API is a hard requirement when selecting an enterprise CMS to store their content in. This is reflected by the recent tendency of enterprise customers to choose DXP platforms or headless CMSs (Contentful, Strapi, Payload, …) over TYPO3 for website relaunches. With the addition of a Delivery API, TYPO3 can be used with traditional templates, as a headless CMS, or in a hybrid setup. This provides all options for using TYPO3 as a content hub in a modern enterprise system landscape.

A proper, strongly typed Delivery API also creates a strong foundation for AI integrations. AI systems depend on structured content and clearly defined interfaces to work with content safely. Typed content models and a machine-readable API specification therefore become major assets when integrating TYPO3 as a content hub into AI workflows.

The Delivery API shall allow frontend access to the CMS content as a JSON API with an OpenAPI Specification and via GraphQL. The formal, machine-readable specification makes it possible to generate up-to-date living API documentation automatically. This allows other application developers to generate API clients based on the specification and access TYPO3 content in a fast and type-safe manner.

On the TYPO3 side, integrators shall be able to activate API support for any TCA table, making its content available in the API with auto-generated models. Relations between records, such as files belonging to content elements, shall be resolved automatically. This allows consumers of the API to navigate, for example, from pages to content to files.
In addition to the auto-generated models, TYPO3 integrators and developers should be able to create their own delivery endpoints and define their own API content models.

Step one: content models

This proposal, “content models”, focuses on the retrieval of content from the TYPO3 database as typed PHP objects. This is not only a first step towards the Delivery API but also has value in itself.

The main idea is to use information from the TYPO3 Schema API (introduced in TYPO3 13) to auto-generate PHP classes for all TCA-defined tables of a TYPO3 instance. Instead of working with untyped arrays or generic record objects, these classes provide a structured and type-safe interface to the CMS content. These classes will be instantiated when records are fetched from the database for page rendering. They can be passed to an external system via an API or used within the template engine to render a page. The types of the content models can be used for:

  • context for AI coding agents
  • context to coding agents while generating templates
  • static semantic checks
  • arguments to Fluid Components

Instead of passing the auto-generated content models directly to the templates or API, developers can also wrap them in view model objects with custom logic. This allows them to implement logic in the content model instead of in view helpers.
This way, template development for pages and content elements will become more similar to the template development for extbase extensions.

In the context of the overall goal, the content models will serve as the foundation of the Delivery API. Their type information will also support the creation of MCP servers to integrate TYPO3 into AI workflows.

Enhancing existing solutions

Some extensions and initiatives already exist that can be extended or built upon:

  • EXT:headless follows a similar goal: It allows developers to render a page and its contents as JSON, to be consumed by a frontend application. With its current technique of specifying the rendering via TypoScript, it does not allow the use of API models, the auto-generation of API documentation, or the use of GraphQL as an additional API format.

  • The TYPO3 Action API will add a remote procedure call (RPC) API to the TYPO3 core. It is built on formal API schemata and includes auto-generated OpenAPI specifications. It will allow developers to register their own API endpoints and is a major leap towards better interconnectivity.
    The view of the TYPO3 Action API is more like the backend of TYPO3. It allows modifications and exposes the complexity of hidden content elements, workspaces, and translations. In itself, it will not provide a rendered frontend view of pages and their content. Once we have content models (this proposal), the TYPO3 Action API might well serve as the foundation for building an API to serve them externally.

  • API extensions like t3api, nnrestapi, and typo3-graphql exist, and most of them provide proper APIs with auto-generated machine-readable documentation. To generate the formal type-safe specification, these extensions mostly rely on models. Unfortunately, these models do not yet exist for the main TYPO3 subjects like pages and content elements. This proposal would provide them.

What must be achieve by 31st of August 2026?

Provide a public open source TYPO3 extension content-models for TYPO3 v14. The extension shall allow developers and integrators to:

  • Generate content models (PHP classes) for their TYPO3 instances
  • Use the content models during page and content rendering
  • Implement custom content models around the generated ones

The extension will provide different flavors of content models (for example, data-transfer objects and lazy record wrappers) and contain examples of how to use the content models with TCA and Fluid components.

What is the potential impact of your idea for the overall goal?

The extension will allow the auto-generation of content models for TYPO3 pages, content elements, and records. In itself this enables type-safe working with the main subjects of TYPO3 like pages and contents in templating. It is the first step towards offering a well-documented, machine readable delivery API. This will allow TYPO3 to be used as a headless and hybrid CMS, so we can combine open source strengths with modern system architecture.
This allows us to keep enterprise projects in the ecosystem, which can otherwise tend to use headless CMS as part of their API-first architectures.

How does your Idea align with the strategic goals for TYPO3 v14.

Strategic Goal 1 — Target Customer Groups
The “Deutschland Stack” for the German public sector has “API-First” as its first architectural principle. Other enterprise customers also require their software components to interact with each other through open standards. Therefore, it is important for these target groups that their CMS provides a state-of-the-art API.

Strategic Goal 2 — Reducing Complexity
Using types to describe data structures in software development has long been a best practice. Initiatives like TypeScript show the importance of types for projects beyond minimal complexity. This proposal provides type information for TYPO3’s core subjects.

Strategic Goal 7 — Improve Interconnectivity
This is the main focus of this proposal. By offering an API, TYPO3 allows external systems to connect to the CMS and work with its data. A JSON-based REST like API together with a GraphQL API is the current common best practice.

Strategic Goal 8 — Give Customers High ROI Through Long-Term Support and Easy Maintenance
By offering an API, TYPO3 instances can be used as headless content hubs when their frontend becomes outdated. The frontend can be replaced and reimplemented while the data remains accessible via the API. This makes investments in TYPO3 sites more future-proof.

Budget for this idea?
10.000 Euro

My Name
Hannes Lau

7 Likes
TYPO3 specific LSP implementations: Fluid (2. Round 2026)
2

Thank you, Hannes, for bringing that up. We seem to have the same struggles with our clients.

That would be a great improvement for our clients and for TYPO3.

1 Like
3

I do believe that content models (this proposal) would be valuable even without the overall goal of a typed delivery API. Working with pages and content elements in PHP Code (with phpstan) is currently a pain, because of all the untyped arrays. It would be great to have type safety and code completion. This makes it easier to work as a human and is also valuable context for AI code generation.

1 Like
4

I don’t want to be the pessemist, but I would highly suggest that before that this shouldb be aligned with the TYPO3 GmbH.

Regarding AI there is work ongoing towards a API (at least for BE for the beginning) with a lot of stuff like OpenAPI spec rendering, route registratin and stuff, OAuth server abilities and similar things - not only on the paper but already on code.

Not looked deeper into these changes, but in general that should be (at later point) possible to open up for “frontend usage”. TYPO3 GmbH (Benjamin Franzke, Frank Nägler) should be possible candidates for contacting on that.

I really wonder why the idee has gotten approved to be published based on that background in the first place.

”Auto generating models” - I must say I know that some are looking for things like that, but knowing and having experiences doing such things already 20 years ago that will never pay out - not on a framework (TYPO3 level) and also creates a lot of god records never used. And when should that happen ? on the fly ? on composer installs ? what about classic mode ? Development time only for a extension - bot for which cases ?

I don’t feel that this budget is right in that form and should not have been published as such.

As already mentioned above, quite a lot of the mentioned things are already in progress and done by the TYPO3 GmbH and paying for a duplicated work ? I don’t know.

Secondly, it’s a common pattern that budgets are requestes to implement things without having a real concept in place which has been aligned with different parties, special for such ideas like this one. Therefore this should have been more a request for a budget to work on a concept and coordinate with different parties (Core Team, TYPO3 GmbH) to have something in the end which can be splittet and implemented and possible additional budgets requested.

Third, the description leaves out a lot of important questsion which would be interessting to decide if the budget idea would go in the “right” direction if voted on.

Fourth - it is mentione that a lot of extensions out there tries to provide an api - this one here would be the next extension in this chain but baked by Associative money ? I don’t know.

There should go work into the TYPO3 core (already in the making) to avoid the “making the next extension out their” and wasn’t it a requirement that budget ideas are cross checked before elected to be voted on to exactly avoid these kind of next to next work and not having something which would end up in the core or a core near implementation.

If a budget is requested for the implementation, how is the plan to maintain that in the “long term” ? Requesting budget for updates again ? What are the exact plan on that ?

Note that for the implementation worked thre is already a lot of things like a json schema builder and similar things.

Removing all the stuff already done or worked on by the TYPO3 GmbH reduces this to the bit of the generator and the budget is way to high for that as being a 2/3 day tasks only for that part - except the avobe quetions on how and wenn to generate these.

Generating them on the fly is a performance issue and also does not ensure they are in sync with definitions and similar. Which is not described how the budget Idee would deal with a lot of these technical questions, but which are important to know beforehand.

I really miss a concrete written concept for the whole stuff or at least a more technical detailed thing.

Just my personal thinking as a casual TYPO3 Association Community member and out of any (team) role.

5

Thank you @stefan.buerk for your detailed (though very pessimistic) feedback :slight_smile:.

Regarding AI there is work ongoing towards a API (at least for BE for the beginning) with a lot of stuff like OpenAPI spec rendering, route registratin and stuff, OAuth server abilities and similar things - not only on the paper but already on code.

Yes, this is true and I am aware of it. You refer to Benjamin Franzke’s work in https://review.typo3.org/c/Packages/TYPO3.CMS/+/91563. It is mentioned explicitly in the proposal with this quote:

The TYPO3 Action API will add a remote procedure call (RPC) API to the TYPO3 core. It is built on formal API schemata and includes auto-generated OpenAPI specifications. It will allow developers to register their own API endpoints and is a major leap towards better interconnectivity.
The view of the TYPO3 Action API is more like the backend of TYPO3. It allows modifications and exposes the complexity of hidden content elements, workspaces, and translations. In itself, it will not provide a rendered frontend view of pages and their content. Once we have content models (this proposal), the TYPO3 Action API might well serve as the foundation for building an API to serve them externally.

You (Stefan) also wrote:

Not looked deeper into these changes, but in general that should be (at later point) possible to open up for “frontend usage”. TYPO3 GmbH (Benjamin Franzke, Frank Nägler) should be possible candidates for contacting on that.

Before submitting the proposal I had a long talk with the Benjamin (you also suggest to contact him in your comment), showing code to each other and discussing the respective solutions. I also sent Benjamin a copy of this proposal before submitting.

To my eyes Benjamin and this proposed work is complementary. Benjamin’s work is focussed towards:

  • API Groundwork (routing, spec generation, json output, …)
  • AI groundwork (MCP, OAuth, …)
  • Implementation for a backend API.

But it does not cover content models or a frontend delivery API. Unfortunately, Benjamin also told me, that his work might not make it into v14 :pensive_face:

A potential second part to this proposal could take the API ground work and build a frontend API on top. This is probably what you refer to as ‘open up for “frontend usage”’. This would also be my preferred way of implementing a frontend delivery API.

But to do so we still need proper types for pages, content and other records (this proposal). Without proper type definitions it is not possible to generate a proper typed, documented API.

The types do not necessarily have to come in the form of PHP classes. We could also use meta descriptions, phpstan types or something else. But the advantage of PHP classes, that php objects can instantiate them, made me prefer the PHP class solutions over the considered alternatives. They can also nicely be used in Fluid Templates and PHP code.

I really wonder why the idee has gotten approved to be published based on that background in the first place.

I am probably not the right person to ask :slight_smile: But, as I said, I already talked to Benjamin, was very happy to hear that an API is coming and shaped my proposal around the future existence of the Action API and its foundation in the core. I explicitly mentioned the Actions API in this proposal. I guess that made it clear that I have thought about it.

”Auto generating models” - I must say I know that some are looking for things like that, but knowing and having experiences doing such things already 20 years ago that will never pay out - not on a framework (TYPO3 level)

Naturally, I tend to disagree here. The models will be generated for a concrete application (one TYPO3 instance) not for the frame TYPO3 per se. In most framework based php applications (Symfony apps, Laravel apps), you do have models to represent your data. It is so much more confortable than untyped arrays.

and also creates a lot of god records never used.

I do believe that the number of php classes generated is pretty harmless. Nevertheless, of course we can add hooks and configuratoin that allow you to leave out classes and properties.

And when should that happen ? on the fly ? on composer installs ? what about classic mode ?

This is a very good question. I am not entirely decided yet. I have a prototype and it just offers a CLI command to regenerate the classes. I run the command after significant TCA changes. Of course this could be automated and run every time the TCA cache is rebuild.
Composer install may also change the TCA and therefore trigger a regeneration. But is more about TCA than composer packages.

Development time only for a extension - bot for which cases ?

See above:

  • Projects that need a Delivery API (e.g. headless)
  • Projects that want to work with typed templates
  • Projects that need to handle pages and content in PHP code. In my projects (some with alternative template engines) I process a lot of content in PHP, before handing of to the template engine. There it would be a great relieve to have proper typed content objects instead of just record objects or untyped arrays.

As already mentioned above, quite a lot of the mentioned things are already in progress and done by the TYPO3 GmbH and paying for a duplicated work ? I don’t know.

As mentioned above: I do believe that this work is complementary and not duplicate.

Therefore this should have been more a request for a budget to work on a concept and coordinate with different parties (Core Team, TYPO3 GmbH) to have something in the end which can be splittet and implemented and possible additional budgets requested.

Aligning with other parties and hammering out a concept will be part of the job and part of the reason that the effort is not minimal.

Third, the description leaves out a lot of important questsion which would be interessting to decide if the budget idea would go in the “right” direction if voted on.

I am happy to answer question of the top of my head right here. But: Expecting a full blown concept before applying for the application would mean that more than half of the work is already done.

Fourth - it is mentione that a lot of extensions out there tries to provide an api - this one here would be the next extension in this chain but baked by Associative money ? I don’t know.

There is no extension yet that lets you easy expose the content from the database via API. “headless” is the next best thing, but is also conceptually missing the models to provide a proper typed API.

There should go work into the TYPO3 core

I agree. I would also be happy to put this into the TYPO3 core. But not every project needs an API and some projects might prefer the dynamic untyped way of working with content. So I suggested to make this an extension first.

If a budget is requested for the implementation, how is the plan to maintain that in the “long term” ? Requesting budget for updates again ? What are the exact plan on that ?

The plan is for the extension to gain popularity, a user base. Of course it would be great if the technology would be picked up by the core. Then I would be happy to maintain the package in the core. If not I will maintain it as a regular extension. I already have some projects that I would use this extension for myself.

Note that for the implementation worked thre is already a lot of things like a json schema builder and similar things.

A json schema builder will not be needed for this, but would be a building block for a potential next step. I am aware that Benjamin is on this. For a frontend API the json schema builder will need type information. This is more than the TCA Schema API can provide. Therefore we would need the content models proposed here.

Removing all the stuff already done or worked on by the TYPO3 GmbH reduces this to the bit of the generator and the budget is way to high for that as being a 2/3 day tasks only for that part - except the avobe quetions on how and wenn to generate these.

A lot of the work is conceptual:

  • When to generate
  • How to get types from TCA? TCA Schema does not provide them. In my prototype I went down to the doctrine level to get the property types.
  • How to work with enumerations? enum classes?
  • How to deal with PageTS overrides?
  • How to build it so it could be integrated into the core?
  • Where to run the hydration? Two steps for page and content? Or build a fake relation $page->getContents($colPos)?
  • public readonly properties? Getters? Both?
  • Where to put the extension points so integrators can wrap their own models around the generated once? Or convert instead of wrap?
  • Wrap the core record objects or copy their values? How about Lazyness?

I already built a prototype to answer some of these questions. But further research and alignment with other parties is also part of the proposed effort.

I really miss a concrete written concept for the whole stuff or at least a more technical detailed thing.

As stated above: A technical concept is part of the proposed effort. I am happy to discuss technical details and the prototype with you and with anyone who is interested. You and me already discussed some details (how to get field types from Doctrine) at the DevDays 2025. I am really happy to further that conversation.

On a seperate note: The notion that ideas can be “disapproved” by a hidden gatekeeper and not even show up to the member vote does not feel democratic to me. To my eyes the disapproved ideas should at least be published together with a reason why they were not approved. Or even better, the concerns should be added as a comment and left for the members to decided upon.

I have the same feeling about the team ideas. To my eyes a plain majority vote on all ideas, without a team fast-track and without a gatekeeper would be the most obvious for the community members to decide where the community budget flows.

6

As the BCC, we approved this idea because we are aware of the plans of TYPO3 GmbH and see it as a strong complement rather than a conflict. From our perspective, it aligns well with the overall direction and does not get in the way of existing or planned initiatives.

7

What I do not understand as a simple assoc member when reading such a negative comment:

  • why is the (planned) work of t3gmbh not mentioned anywhere?
  • Why is it not on the roadmap for any major version?
  • Why are there no news about on t3-com with updates on the progress (14 finals in a few days)?
  • Why is the ongoing work or parts of it not on gerrit as all of this looks like a bigger epic with many patches to me.
  • Where can I find the epic for it on forge?
  • Do I have to attend all official events where all of this stuff was probably communicated already? :face_with_raised_eyebrow:

Can‘t find anything