🐛 Describe the Bug
The v2 Email Templates API documentation contradicts itself regarding the editorContent parameter when editorType="builder". The parameter table defines editorContent as an object, but the example payload shows an HTML string.
If we send a String: The request fails with a 422 error ("editorContent must be an object").
If we send an Object: The request bypasses validation but crashes the backend with a 500 error ("Fail to save the builder details for templateId , msg: Cannot read properties of undefined..."). The template is partially created in a broken state and must be manually deleted.
📍 API Endpoint
POST /emails/public/v2/locations/:locationId/templates
✅ Expected Behavior
The documentation should clearly document the exact JSON schema required for the editorContent object. Furthermore, if a malformed object is sent, the API should return a standard 400 Bad Request, not crash with an unhandled 500 Internal Server Error that leaves partially created garbage data in the user's account.
💻 Screenshots or Code Samples
Environment details for the 500 crashes:
Location ID: [REDACTED_LOCATION_ID]
Scopes: emails/builder.write, emails/schedule.write
Auth: Sub-Account OAuth access token
Trace IDs from failed 500 calls:
5a414efa-6e46-4da4-ba40-c291b68fd966
d871200f-d579-4549-9641-48cf4018f600
11e4394c-86ea-4d41-bf2a-f0dd0d3905a6
Product Area
emails
📋 Use Case
We are building a marketplace app that needs to programmatically generate drag-and-drop email templates for our users. Currently, we are forced to use editorType="html" as a workaround. This degrades the user experience because our users cannot edit the templates we generate using the HighLevel visual builder.
🚨 Why Should This Be Prioritized?
Server Stability (Unhandled Exceptions): The current endpoint lacks proper validation for the builder object, allowing standard API requests to trigger unhandled 500 Internal Server Errors. External integrations shouldn't be able to crash the backend parser.
Data Integrity (Database Pollution): Because the backend crashes mid-execution, it leaves partially created, corrupted template artifacts in the user's HighLevel account. This pollutes the database and forces developers to build automated cleanup routines (DELETE requests) just to handle the undocumented crashes.
Marketplace Ecosystem Blocker: As a marketplace app (AESync), our inability to programmatically generate visual builder templates severely degrades the onboarding experience for our users. We are completely blocked from fully integrating with the builder until the editorContent JSON schema is accurately documented.
🧠 Additional Context
Is editorType="builder" actually supported via the public v2 REST API for programmatic creation? (We noticed the GHL UI appears to write builder JSON directly to Firestore).
If programmatic creation of builder templates is NOT supported, please update the documentation to explicitly state this limitation so developers stop trying to guess the schema.
🐛 Describe the Bug
The v2 Email Templates API documentation contradicts itself regarding the editorContent parameter when editorType="builder". The parameter table defines editorContent as an object, but the example payload shows an HTML string.
If we send a String: The request fails with a 422 error ("editorContent must be an object").
If we send an Object: The request bypasses validation but crashes the backend with a 500 error ("Fail to save the builder details for templateId , msg: Cannot read properties of undefined..."). The template is partially created in a broken state and must be manually deleted.
📍 API Endpoint
POST /emails/public/v2/locations/:locationId/templates
✅ Expected Behavior
The documentation should clearly document the exact JSON schema required for the editorContent object. Furthermore, if a malformed object is sent, the API should return a standard 400 Bad Request, not crash with an unhandled 500 Internal Server Error that leaves partially created garbage data in the user's account.
💻 Screenshots or Code Samples
Environment details for the 500 crashes:
Location ID: [REDACTED_LOCATION_ID]
Scopes: emails/builder.write, emails/schedule.write
Auth: Sub-Account OAuth access token
Trace IDs from failed 500 calls:
5a414efa-6e46-4da4-ba40-c291b68fd966
d871200f-d579-4549-9641-48cf4018f600
11e4394c-86ea-4d41-bf2a-f0dd0d3905a6
Product Area
emails
📋 Use Case
We are building a marketplace app that needs to programmatically generate drag-and-drop email templates for our users. Currently, we are forced to use editorType="html" as a workaround. This degrades the user experience because our users cannot edit the templates we generate using the HighLevel visual builder.
🚨 Why Should This Be Prioritized?
Server Stability (Unhandled Exceptions): The current endpoint lacks proper validation for the builder object, allowing standard API requests to trigger unhandled 500 Internal Server Errors. External integrations shouldn't be able to crash the backend parser.
Data Integrity (Database Pollution): Because the backend crashes mid-execution, it leaves partially created, corrupted template artifacts in the user's HighLevel account. This pollutes the database and forces developers to build automated cleanup routines (DELETE requests) just to handle the undocumented crashes.
Marketplace Ecosystem Blocker: As a marketplace app (AESync), our inability to programmatically generate visual builder templates severely degrades the onboarding experience for our users. We are completely blocked from fully integrating with the builder until the editorContent JSON schema is accurately documented.
🧠 Additional Context
Is editorType="builder" actually supported via the public v2 REST API for programmatic creation? (We noticed the GHL UI appears to write builder JSON directly to Firestore).
If programmatic creation of builder templates is NOT supported, please update the documentation to explicitly state this limitation so developers stop trying to guess the schema.