Why integrations are modeled as workspace-owned installations with child credentials and verified origins.
Status
Section titled “Status”Accepted.
Decision
Section titled “Decision”Legaciti models external CMS integrations as:
workspace -> installation -> credential
with origin/domain treated as a verified installation attribute rather than the durable identity.
- Existing public API key metadata was sufficient for partner writes, but not for a long-term product surface.
- Installations give Legaciti a stable control-plane entity for verification, credential rotation, quotas, audit history, and future multi-site support.
- Credentials remain replaceable security artifacts instead of becoming the business model.
- The dashboard remains the human control plane; the consumer API worker remains the machine-facing runtime plane.
Consequences
Section titled “Consequences”- Installation control-plane state is centralized and unsharded.
- External plugin consumers move to
/integrations/v1. - Dashboard installation UI stays app-local.
- Shared contracts and domain logic move to packages.
- Consumer implementations can live in separate repositories as long as they conform to the published integrations contract.
Non-goals
Section titled “Non-goals”- Full CMS implementation parity inside this monorepo.
- Repo-wide rename before functional seams exist.
- WordPress-specific assumptions inside the shared integration core.
- Coupling this monorepo to any single external consumer repository.