I'd suggest a hierarchical approach:

1. If templates are defined, through templates (CMS_TEMPLATES setting)
   • Backwards compatible
   • Only one place to change if using both django CMS' headand API
   • Allows for additional config, namely inheritance.
2. If no templates are defined, fall back to a new setting, say,

   CMS_PLACEHOLDERS = (    ("home", ("content", "sidebar"), _("Home page")),  # Give slot names    ("products", ("intro", "ads", "disclaimer"), _("Product page")),)

3. If no setting exists at all: Just one placeholder per page, called"content".

If inheritance is important for a headless solution, theCMS_PLACEHOLDERS could add an optional config, despite the fact it might look clunky:

CMS_PLACEHOLDERS = (    ("home", (        "content",  # Shorthand for {"slot": "content", "inherit": False}        {            "slot": "sidebar",            "inherit": True,        }    ), _("Home page")),    ...)

See here for an early test run:#7850 (comment)

On another note, allowing for an alternative method of placeholder declaration - besides within templates - will simplify certain use cases for app hooks:

• Currently, app hooks need to define aget_template() method on their frontend-editable models to provide a template for placeholder scanning only. Often, it only lists the placeholders using the{% placeholder %} template tag.
• Typically, a different template is used for actually displaying any model content using{% render_placeholder %} instead of{% placeholder %}

I suggest to also checking models for aget_placeholder_slots() method which will return a model's used slots. It will be evaluated in cases theget_template() method does not exist or returns a valid template.