[Feature New API] Add PUT /funnels/page/data endpoint for page builder content writes #267
Description
🌟 Describe the Feature
Hi HighLevel API Team,
I'm a HighLevel customer and developer (Location ID: RX5OgsBRHELAtg09yr6K) building automated content workflows, and I'm writing to request API write access for page builder content.
What works today:
GET /funnels/page/data successfully returns the complete page builder JSON, including all elements, custom HTML blocks, styles, and version numbers. This is an excellent endpoint.
What's missing:
There is no corresponding write endpoint. PUT /funnels/page returns 401 "This route is not yet supported by the IAM Service" for all auth types (PIT token, OAuth2, Firebase JWT). No funnels/page.write scope exists in the OAuth scope catalog, and the official OpenAPI spec contains zero page write operations.
Why this matters:
I manage sales pages with large custom HTML blocks (25,000+ characters) that I update programmatically. Without an API write endpoint, I'm forced to use browser automation to open the page builder, click into the code editor, paste content, and click save. This is slow, fragile, and breaks whenever the UI changes.
What I'm requesting:
A PUT /funnels/page/data endpoint (or similar) that accepts the same JSON structure returned by the GET endpoint and updates the page builder content. Your Blog API already supports this exact pattern with PUT /blogs/posts/{postId} accepting rawHTML content — the page builder just needs the same treatment.
The inconsistency I don't understand:
You've built a read endpoint that returns the full page builder data structure, which implies the internal architecture already supports external access to this data. But writes are locked inside the Firestore channel protocol with no public surface. If the data can be read via API, why can't it be written via API?
This would be a high-value addition for any developer building automated content pipelines, A/B testing workflows, or multi-location page management on HighLevel.
Thank you for considering this.
Caesar
🚀 Justification
The GET /funnels/page/data endpoint already returns the complete page builder JSON structure — all elements, custom HTML content, styles, and version numbers. But no corresponding write endpoint exists. There is no funnels/page.write OAuth scope, no PUT/POST endpoint in the OpenAPI spec, and the existing PUT /funnels/page route returns "not yet supported by IAM Service." The read infrastructure is built — the write surface just needs to be exposed.
📝 Suggestions
Add a PUT /funnels/page/data endpoint that accepts the same JSON structure returned by GET /funnels/page/data. Add a corresponding funnels/page.write OAuth scope. The Blog API already follows this exact pattern with PUT /blogs/posts/{postId} accepting rawHTML — the page builder just needs the same treatment.
Product Area
funnels
📋 Use Case
I manage funnel sales pages with large custom HTML blocks (25,000+ characters) that are updated programmatically as part of automated content workflows. Without a write API, I'm forced to use fragile browser automation — opening the page builder, clicking into the code editor, pasting content, and clicking save. This breaks whenever the UI changes and can't be reliably scheduled or integrated into CI/CD pipelines.
🚨 Why Should This Be Prioritized?
The read endpoint already exists and works, meaning the internal architecture supports external access to page builder data. The only missing piece is exposing the write path. This would unlock automated content deployment, A/B testing workflows, multi-location page management, and AI-powered content generation pipelines for every HighLevel customer building with the API. The "API for website builder" request on the Ideas Board already has community votes — demand exists.
🧠 Additional Context
Tested exhaustively: PIT tokens, OAuth2 apps, Firebase Auth JWTs, and Firestore REST API — all blocked. OAuth2 does not unlock additional routes vs PIT tokens. Firestore direct access is blocked by App Check. Browser automation is currently the only viable workaround, which is unreliable for production use.