You can define custom properties on HubSpot's Marketing Email object. You can see them in the UI. You can even confirm they exist via the Properties API. What you cannot do is read their values programmatically. This is not a configuration error or a missing scope. It is a structural limitation that affects any team trying to build automated content performance tracking, email governance workflows, or cross-system reporting.
The gap surfaced again this week in a HubSpot Community thread where a developer documented the exact failure mode: the Properties API returns the custom property definition for object type 0-29 (Marketing Email), but neither the Marketing Emails API nor the CRM Objects API will return the property values. The CRM Objects endpoint explicitly rejects MARKETING_EMAIL as an unsupported object type. The Marketing Emails API's includedProperties parameter filters only the email's native schema fields, not custom properties.
For marketing operations teams that have invested in tagging emails with metadata like "has CTAs," "campaign tier," or "content pillar," this means the data exists only in the UI. It cannot feed dashboards, cannot trigger workflows based on email attributes, and cannot sync to external BI tools without manual intervention.
Why This Matters for Content-to-Revenue Tracking
Custom properties on marketing emails are not cosmetic. They are the mechanism for building content telemetry that connects email performance to pipeline outcomes. A typical use case: tag each email with its content type, funnel stage, and primary CTA category. Then correlate those tags with downstream metrics like influenced pipeline, opportunity velocity, or closed-won attribution.
Without API access to those property values, the correlation breaks. You can pull email performance metrics (opens, clicks, sends) via the Marketing Emails API. You can pull deal and contact data via the CRM APIs. But you cannot programmatically join them on the email's custom metadata because that metadata is not exposed.
A recent analysis of HubSpot's API surface noted that roughly half of what clients ask for is completable end-to-end via the public API. Marketing email custom properties fall into the other half: the data exists, but the endpoint does not.
The Three Workarounds That Actually Work
The community has converged on three approaches, each with different trade-offs for latency, maintenance burden, and data fidelity.
Custom Reports with Manual Export
Build a custom report in HubSpot using the Marketing Emails data source, add your custom properties as columns, and export to CSV. This is the approach confirmed by community members as the most reliable path to getting email ID paired with custom property values. The limitation is obvious: it is not real-time, it requires manual execution, and it does not scale to automated pipelines. For quarterly board reporting or ad-hoc analysis, it works. For daily operational dashboards, it does not.
Maintain a Parallel Mapping Table
Store your custom property values in a system you control, keyed by HubSpot email ID. When you create or update an email in HubSpot, write the same metadata to your mapping table (a simple database, a Google Sheet, or a row in your data warehouse). When you need to join email performance data with custom attributes, pull performance from HubSpot's API and join it against your mapping table.
This approach adds maintenance overhead and introduces a sync risk: if someone updates the custom property in HubSpot's UI without updating your table, the data drifts. But it gives you real-time API access to the metadata you need.
Shift Metadata to an Associated Object
Instead of storing custom properties on the email itself, create a lightweight custom object (call it "Email Metadata" or "Content Tag") and associate it with the email via HubSpot's Associations API. Custom objects are fully supported by the CRM Objects API, so you can read and write their properties programmatically.
The trade-off is architectural complexity: you are now managing associations, and your reporting logic must traverse those associations to join email performance with metadata. For teams already using custom objects for other purposes, this may be a natural extension. For teams that have not, it is a significant lift.
What This Means for Your MarTech Stack Decisions
The marketing email custom properties gap is a specific instance of a broader pattern: HubSpot's API surface does not always match its UI capabilities. As one API guide for marketing analysts noted, custom properties multiply faster than documentation can keep up, and schema changes can invalidate pipelines without warning.
Before committing to a metadata architecture in HubSpot, test the API path. Define a custom property, populate it on a test record, and confirm you can read the value via the API you plan to use. If the endpoint returns the property definition but not the value, you have found a UI-only feature.
For teams evaluating HubSpot against other platforms, this is a due diligence item. Ask the vendor: for every object type that supports custom properties in the UI, can I read and write those property values via the public API? The answer is not always yes.
The Pilot Plan
If you are currently blocked by this limitation, here is a two-week path to a working solution:
Week One
Audit your existing custom properties on the Marketing Email object. Identify which ones are critical for reporting versus nice-to-have. For critical properties, decide whether the custom report export cadence (weekly, monthly) is acceptable or whether you need real-time access.
Week Two
For properties requiring real-time access, implement the mapping table approach. Build a simple webhook or integration that writes to your mapping table whenever an email is created or updated. Test the join logic against your existing email performance queries.
Risk Mitigation
Document the sync process and assign ownership. If the mapping table drifts from HubSpot's UI values, you need a reconciliation process. A monthly audit comparing your table against a custom report export will catch drift before it corrupts downstream analysis.
The gap is real, but it is not insurmountable. The question is whether the workaround cost is worth the metadata value. For teams building serious content-to-revenue attribution, it usually is.
