Updates to rawHTML elements via POST /content/elements are saved correctly to the API (verified by GET /content/elements/:id returning the new content immediately), but the live B1App public page continues to serve the old content for an extended period.
Reproduction on onechurch.b1.church/ai-setup:
GET /content/elements/mjBBus2l731 → confirm current rawHTML
POST /content/elements with updated rawHTML → 200 OK
GET /content/elements/mjBBus2l731 → immediately returns new content ✓
curl https://onechurch.b1.church/ai-setup → still serves old HTML 35+ minutes later
Note: Other pages on the same site (e.g. onechurch.b1.church/one-church-action-plan) propagate changes in ~30 seconds using the same POST endpoint and same API key. The behavior is inconsistent between pages.
The long cache TTL makes iterative content editing impractical — authors have no way to verify their changes are correct on the live site.
Updates to
rawHTMLelements viaPOST /content/elementsare saved correctly to the API (verified byGET /content/elements/:idreturning the new content immediately), but the live B1App public page continues to serve the old content for an extended period.Reproduction on
onechurch.b1.church/ai-setup:GET /content/elements/mjBBus2l731→ confirm current rawHTMLPOST /content/elementswith updated rawHTML → 200 OKGET /content/elements/mjBBus2l731→ immediately returns new content ✓curl https://onechurch.b1.church/ai-setup→ still serves old HTML 35+ minutes laterNote: Other pages on the same site (e.g.
onechurch.b1.church/one-church-action-plan) propagate changes in ~30 seconds using the same POST endpoint and same API key. The behavior is inconsistent between pages.The long cache TTL makes iterative content editing impractical — authors have no way to verify their changes are correct on the live site.