HubSpot CMS for Developers
Domain overview
The HubSpot CMS for Developers exam tests your ability to build maintainable themes, templates, and modules with HubL, connect content to HubDB and CRM data, and ship performant, secure pages. Expect scenario questions about local development, module structure, dynamic pages, and API-backed content rather than trivia.
Core rules and concepts
- HubL uses {{ }} for output and {% %} for logic. Filters such as |escape, |default, and |truncate change output safely.
- A custom module needs module.html plus fields.json for editor fields and meta.json for metadata. Use hs create module, hs upload, and hs watch for local work.
- Page templates use {% extends %} and {% block %} for inheritance; partials use {% include %} or {% module %}.
- Dynamic pages bind a template to a HubDB table or CRM object, then render rows with hubdb_table_rows or object filters.
- Serverless functions live under .functions and are called at /_hcms/api/; use private-app tokens with least-privilege scopes for external APIs.
Worked example
You need a testimonial grid driven by a HubDB table. Create a page template that sets {% set rows = hubdb_table_rows(123456) %}, loops with {% for row in rows %}, and outputs {{ row.quote|escape }} and {{ row.author|default("Customer") }}. The reasoning: table ID is data, not markup; escape user-entered quotes to prevent XSS; default avoids empty labels. Add a module field of type hubdb if editors must choose a different table.
Traps that cost marks
Do not put logic in {{ }} or forget endfor/endif. Do not hardcode table IDs if a module field can supply them. Do not render raw HTML from HubDB without sanitizing. Do not assume serverless functions are public without auth; protect them with request signatures or tokens. Do not ignore caching when testing dynamic content.