I’m building an external Node.js CMS integration using OAuth. It updates page-specific H1 text, link URLs and image URLs. Before changing a field, I need to verify that it actually controls the selected rendered element, while protecting global/shared content. Matching a unique text value alone is not enough.
I’m having trouble retrieving verifiable source for native Elevate React Heading and Button modules, even though they render correctly and are editable in HubSpot’s page editor.
What I tested
These were read-only tests in a developer test account on 3 November 2026, using the same OAuth connection with content and oauth scopes.
Module lookup by ID GET /content/api/v4/custom_widgets/{moduleId} returns 404 for the native Elevate Heading and Button. The same connection returns 200 for account-owned React modules, including a global React module.
Module lookup by path GET /content/api/v4/custom_widgets/by-path/{path} returns 200 for @hubspot/elevate/components/modules/heading and @hubspot/elevate/components/modules/button. The response includes field definitions, global: false and isJsModule: true. However, source contains only a comment beginning custom widget definition not found, rather than the renderer source.
Source Code API and filemapper
Published metadata/content requests through the 2026-09 Source Code API returned 404 for the native paths I tested. I also tried the download-default and stream routes used by HubSpot’s own local development library, directly over HTTP with the same OAuth connection. Those returned TSX under @hubspot/elevate-react/components/modules/Heading/index.tsx and the corresponding Button path. I could not establish that these files are bound to the exact module build deployed on the page, or find a documented support contract for using those routes in an external integration.
Inline-editing markers
The rendered H1 has a marker with this structure:
In my test, the module instance, stored field value and schema matched, and the field was type: text with inline_editable: true. Button text also has a marker, but that does not identify its href field. I also observed these markers in global header content, so I’m not treating the marker alone as proof that content is page-specific.
Questions
Is the placeholder source response expected for native Elevate/React modules? Is there a supported OAuth endpoint, newer API or additional scope that returns the actual renderer source for the deployed module version?
Are the filemapper download-default/stream routes supported for external OAuth integrations? If so, how can a caller identify the deployed module’s source revision?
Is data-hs-token, together with the page’s module instance and field schema, a supported and stable way to identify editable plain-text fields? Are there documented guarantees or restrictions for global content, repeaters, links and images?
What additional details would help investigate this? I can provide sanitized request/response samples, timestamps, correlation IDs and a minimal reproduction. Account-specific details can be shared privately with HubSpot Support if needed.
My goal is to support these editable fields without modifying the customer’s theme or requiring CLI access, using a supported mechanism that reliably identifies the intended field.
Hi @pranavlari, getting back to you on this! I’d be happy to share a bit more context.
Elevate source
The Elevate theme source is available in HubSpot’s public repository, which can be used as a reference or starting point for customization. I can’t confirm behavior for undocumented routes, so I wouldn’t recommend relying on them.
data-hs-token
The Elevate repository notes that inline-editing functionality such as data-hs-token is available in the default Elevate theme, but not in child themes or custom implementations. I’d treat any token format inferred from the source as an implementation detail, not a supported contract.
Default module version
For default modules, get_asset_version("@hubspot/module-name") can be used to check the module version. You can also view version information in Settings > Content > Themes & Modules. See Default module versioning.
I hope this helps and please let us know if you have additional questions.
Bérangère, HubSpot Community Manager
This post was created with the assistance of AI tools
just a quick disclaimer - I’m not the biggest fan of the Elevate theme as it still comes with a “beta” taste.
As for for request: GET /content/api/v4/custom_widgets/{moduleId} works only for custom modules.
Since Elevate (and it’s modules) are flagged as HubSpot default, the custom_widget doesn’t work here.
My recommendation would be to create custom modules with the functionality you’re looking for.
Is the placeholder source response expected for native Elevate/React modules?
The source endpoint is only for Design-Manager elements, not projects (like Elevate)
Are the filemapper download-default/stream routes supported for external OAuth integrations?
No, as they’re internal APIs.
Is data-hs-token, together with the page’s module instance and field schema, a supported and stable way to identify editable plain-text fields?
No, it’s a HubSpot internal thing which is handled by HubSpot.
Something I’d recommend to look at:
Rather than modifying a module, modify the page with the Pages API as modifying a module will change the content of it globally in every instance of it and most likely lead to unwanted results or breaking things.
Content and theme-functionality/modules are two different things in HubSpot. The theme itself doesn’t need to be modified per instance. Only if the customer has specific requirements which require custom development. You can’t modify the content via CLI, only API (see Pages API)
In general HubSpot themes work like this:
Theme - a collection of modules, templates, sections and other elements
modules - individual building blocks for pages
local modules - can have individual content per instance
global modules - have the same content per instance
(saved) sections - group/laoyut of several modules, ready to drag&drop
templates - reusable page layout; can be modified per page; modified page templates are being disconnected from the original template (change something like a text element on the page → disconnect).
Changes to templates on code-level will affect only future pages, not existing pages based of this template
dynamic templates - reusable templates for something like HubDB or custom object content
and welcome!