Documentation Index

Fetch the complete documentation index at: https://docs.aifabrix.ai/llms.txt

Use this file to discover all available pages before exploring further.

Build with Builder MCP

  • Published on Jun 29, 2026
  • 1 minute(s) read
  • MR
  • EB
 Prev Next

Human integrators and AI agents follow the same manifest development loop when editing Connected Systems and Business Entities through Builder API or CLI.

Why it matters

Agents must not patch manifests blindly. The governed loop — read, resolve missing inputs, patch with intent, repair derived sections, validate, test — matches what experienced integrators already do locally with repair and validate.

Prerequisites

  • Builder CLI or Builder API access with authentication
  • Local workspace under integration/<systemKey>/ or online manifest via Builder API

Normative loop

  1. Read a governed manifest section before any write (section read token when using Builder API).
  2. Ask when required inputs are missing — do not invent primary keys, entity types, or similar values.
  3. Patch with intent — every write records why the change was made.
  4. Repair explicitly — pass named repair hooks after patches that affect derived sections.
  5. Validate and test — schema and integration tests before upload.
  6. Upload separately — upload and certification are not automatic side effects of patch.

Typical sequence

Start with Business Entity metadata for a new entity. Patch with intent describing the vendor payload mapping. Repair fieldMappings, expose, and rbac hooks. Patch openapiOperations when adding write capabilities. Repair again, validate, then test. Upload when ready.

Post-upload authentication (enterprise handoff)

Validate, test, test-integration, and upload must not depend on resolved integration secrets in Builder API scope. Upload publishes configuration including non-secret authentication variables. The user adds live secrets in the dataplane Connected Systems → Authentication UI afterward.

After upload succeeds:

  1. Read authentication.authType and credential method from the published system manifest.
  2. Confirm non-secret variables (baseUrl, headerName, tokenUrl, and similar) were set — they pre-fill in the UI.
  3. Ask the user for their dataplane public UI base (origin including /data).
  4. Direct the user to add only required secrets in Authentication — not vendor tokens in Builder API or workspace env files when UI authentication is the intended path.
  5. Re-run E2E or live verification after secrets are saved.

Builder help topics (reference)

See the full topic registry and manifest section keys on Build reference.

Related articles