Marketing Data BFF Content Intent Model¶
Purpose¶
This document captures the current site-facing marketing BFF surface for articles, article collections, products, product collections, properties, and related consumption rules.
Core Direction¶
- keep local docs focused on intent and usage rules
- use BFF object keys and returned identifiers as authority
- do not create local shadow content stores for article or product objects
Domain Layout¶
docs/articles/describes article-domain usage and persistence rulesdocs/products/describes product-domain usage and retrieval rulesdocs/sites/describes how each site consumes those BFF-backed objects
Live Endpoint Base¶
https://dirac-fed-dev.omnivoltaic.com/article-bffhttps://dirac-fed-dev.omnivoltaic.com/product-bff
Verified Endpoint Families¶
Article¶
getArticlegetArticleBySluglistArticlescreateArticleupdateArticledeleteArticle
Article Collection¶
getArticleCollectionlistArticleCollectionscreateArticleCollectionupdateArticleCollectiondeleteArticleCollectionaddArticlesToCollectionremoveArticlesFromCollectionreplaceArticlesInCollection
Product¶
getProductgetProductBySluglistProductscreateProductupdateProductdeleteProduct
Product Collection¶
getProductCollectionlistProductCollectionscreateProductCollectionupdateProductCollectiondeleteProductCollection
Property¶
getPropertygetPropertiesByKeys
Operating Rules¶
- BFF-returned slugs and keys are canonical.
- Product and article delivery apps may cache fetched BFF payloads during build, but those caches are not source-of-truth.
- If a field does not faithfully round-trip through the live BFF, do not describe it as authoritative persisted content.
Known Constraint¶
Property-definition mutations were not part of the documented live product-bff surface during prior verification and must be re-verified before being treated as available.