Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Please sign in to leave a comment.

Comments

2 comments

Date Votes
  • Official comment
    Sadie Martin Fivetranner

    Hi Vivek,

    Sadie from the Product team here. We're currently using a different endpoint to retrieve marketing emails (https://legacydocs.hubspot.com/docs/methods/cms_email/get-the-details-for-a-marketing-email), which only returns the template, as you've mentioned. We haven't implemented the endpoint you linked yet because it is still in beta. We try to be careful about making use of endpoints that could still change without notice. That being said, I can understand the value of this data. We'll reach out to HubSpot to inquire about the stability to see if we can add this to our backlog.

    In the meantime, would you mind sharing a bit more about your use case for the data? How do you plan to use it?

    Best,

    Sadie

  • Jayaram Devineni User
    • Edited

    Following up on this two years on, because the stated blocker has since resolved.

    HubSpot's Marketing Email API v3 reached GA in April 2025, and the v1 endpoint
    (/marketing-emails/v1/*) was sunset on 1 November 2025, so the "still in beta, could change
    without notice" concern no longer applies. The connector already reads v3 for the rest of the
    MARKETING_EMAIL table — the folderId to folderIdV2 migration you changelogged in October 2025
    is v3 behaviour.

    To answer Sadie's question about the use case: we build account activity timelines from
    marketing email sends. Today every bulk send shows only an internal campaign code, so the
    record is unreadable. A user can see thirty marketing touches and learn nothing from any of
    them. MARKETING_EMAIL.subject already gives us the subject line, which helps enormously. The
    body would let us show what was actually said, and would let analysis tools reason over the
    content rather than only the fact of a send.

    Concretely, from GET /marketing/v3/emails we would want:

    - content.plainTextVersion — the plain-text body. This alone would cover most of the value,
      and it avoids any HTML sanitisation burden on the consumer side.
    - content.templatePath — useful where the body itself is unavailable.

    For context on the current behaviour: the existing email_body column is populated with the
    HubL template placeholder rather than content, which matches your description of the legacy
    endpoint returning only the template.

    Happy to help validate against a real instance if that would be useful.