Data structure documentation? No?


Hi all,

is there any documentation on the content data? E.g. for the call

Is there a documentation on the data structures itself? Am I missing something? (Yes, I have already scrolled a little in the page mentioned above - but that "structure documentation" is far from being sufficient).

I am especially struggling with the "widgets" structure...

Thank you


Hi @Steffen, it doesn't look like we have this in our public documentation. We agree with you that our docs have a lot of updating (currently in the midst of doing so). I can bump this to the top of our list. What you could do is make a page with many widgets on it, make a GET to this endpoint:, then see how those widgets are formatted, to make your PUT request here: I'm reaching out about the docs now with my team.


Hi @Connor_Barley!

Thank you for your response and commitment. Actually, I already have a response from a "get page by id" request and the resulting data structure confuses me. Maybe you happen to know:

  • Cloned modules share the "module_id" with its origin, although they may have been altered (in my case, the CSS was changed). How can I reliably tell origin and clone apart? Is the unique key to a module instance actually "module_id" AND "label"?
  • Widgets have the "type" field set (e.g. to "rich_text", "logo") whereas modules will always return "module" and have their "module_id" set. Unfortunately, for widgets we do not have a "module_id". Is there a generic way to process widgets and modules by type? Is there some kind of unique and stable type id?


Hmm @Steffen, I can't quite visualize what you mean at the moment. Do you have a template I could use so I can make a GET to see what you're seeing? You can just link the template in this thread.


Hi @Connor_Barley !

Unfortunately, I'm unsure which data I can reveal and therefore have blackened some irrelevant parts. But in my screenshot (from Postman), you can see the response to a "get email by id" call.

In the "widgets" structure we see those three unfolded elements:

  • "hs_email_body" which is of "type" "rich_text" but lacks a "module_id"
  • "module_...269" which is of "type" "module" and has a "module_id"
  • "module_...913" which is of "type" "module" and has THE SAME "module_id" as module ...269 (because the module was cloned and its CSS changed)

Now when processing the "widgets" structure by type (type as seen by the content managers - not as defined in the JSON), I am unsure which key I should base the processing on. How can I tell these three items apart by its (user-visible) type? What is the unique key of type of a widget / module?


Hi @Steffen,

Looks like you're using an undocumented endpoint. There currently isn't a public Email (for content) API; that endpoint appears to be an internal endpoint that still functions with external auth. Anything that isn't publicly documented in our Developer Docs isn't officially supported and is prone to be changed/deprecated without warning so I wouldn't suggest coding against that endpoint.

I can speak to overall structure in hubspot if you end up using the documented endpoints like this one:

  • Module IDs can be shared. If I have a Custom Module I built for banner images, that module can be placed on multiple pages and more than once per page. The module_id will be the same. The thing that will change would be the module instance ID i.e. "module_XXXXXXXXXXXXXX"
  • hs_email_body is a default field that cannot be added more than once to a template so there's no id.


Hi @Connor_Barley,

thank you for your support and the fair warning.

I still do not understand though... The highlighted modules instances ...269 and ...913 have the same "module_id" although they have different CSS in the mail template - and they are considered to be different modules by the users (content managers).
Is there any way to tell these module instances apart by what the content managers would call a "type" except by using the "label"? Do you have an internal unique primary key which is just not exposed?
Using the module instance id is not an option since that would defy the point in implementing a custom adapter in the first place (we want to automatically process zounds of module instances).


Hey @Steffen, right, but let's say the same module, for example a module in my account called "dev forum test" (, is dragged onto two different email templates. On the template or individual email level, I can edit the module properties and default text etc. While they're now deviated from the original way the module looked, the source of those two modules still comes from my "dev forum test" module, and thus have the same ID. They are, however, different instances of the same module, which is why you see ..269 and ..913. The module instances themselves indicate that they are different instances of the same module, so that would be the way to differentiate them. There is no unique primary key that is not surfaced. The name property you can see in your screenshot contains the module instance ID, so you could conceivably differentiate modules based off that one property instead of looking at the high level module_XXXXXX object