Skip to content

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 rules
  • docs/products/ describes product-domain usage and retrieval rules
  • docs/sites/ describes how each site consumes those BFF-backed objects

Live Endpoint Base

  • https://dirac-fed-dev.omnivoltaic.com/article-bff
  • https://dirac-fed-dev.omnivoltaic.com/product-bff

Verified Endpoint Families

Article

  • getArticle
  • getArticleBySlug
  • listArticles
  • createArticle
  • updateArticle
  • deleteArticle

Article Collection

  • getArticleCollection
  • listArticleCollections
  • createArticleCollection
  • updateArticleCollection
  • deleteArticleCollection
  • addArticlesToCollection
  • removeArticlesFromCollection
  • replaceArticlesInCollection

Product

  • getProduct
  • getProductBySlug
  • listProducts
  • createProduct
  • updateProduct
  • deleteProduct

Product Collection

  • getProductCollection
  • listProductCollections
  • createProductCollection
  • updateProductCollection
  • deleteProductCollection

Property

  • getProperty
  • getPropertiesByKeys

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.