Hydrix Docs

Build & Integrate

Build and integrate a Hydrix site.

Use this page as the implementation hub for repository build requirements, runtime /admin and /data integration, and launch validation.

Hydrix site implementations currently use EXTERNAL_REPO or HYDRIX_GIT. Client teams normally do not hand-author site config JSON; Client Portal stores and validates that configuration. Use the API page for endpoint-level contracts and Support for troubleshooting paths.

Client Portal setup

  • Choose EXTERNAL_REPO or HYDRIX_GIT in the site setup flow.
  • Confirm domain, admin users, and deployment settings in Client Portal.
  • Let Hydrix manage schema validation and stored site configuration.

build.yml

  • Keep build.yml at the repository root.
  • Build static assets into one deterministic directory.
  • Align ARTIFACT_DIR with the configured artifact directory.

Runtime integration

  • Bootstrap admin clients from GET /admin/public/config.
  • Integrate the auth boundary for /admin/* and /data/*.
  • Use GET /data/auth/config and GET /data/auth/methods as the runtime auth source of truth.
  • Pass providers.google.scopes through unchanged when building Google Hosted UI authorize URLs.
  • Validate email, mailbox, and forwarding flows when enabled.

Implementation Path

  1. Choose the frontend source mode for the site.
  2. Complete site setup in Client Portal.
  3. Add a repository-root build.yml.
  4. Align build output with repo.artifactDirectory or repoBinding.artifactDirectory.
  5. Provision and deploy the site through the Hydrix control plane.
  6. Integrate admin bootstrap, auth, and runtime admin flows.
  7. Integrate public and authenticated data operations.
  8. Run go-live validation for auth, data, and email behavior.

Frontend source mode

  • EXTERNAL_REPO uses an external git repository as the site source.
  • HYDRIX_GIT uses the Hydrix-managed git path and repo binding.
  • Keep the selected source mode aligned with the site setup saved in Client Portal.

Auth pattern

  • Admin clients can use Hosted UI bootstrap or fully custom Cognito login.
  • /admin/api/* and /admin/data/* use the site admin token.
  • /data/{operation} uses the site data-system access token.
  • If Google sign-in is enabled, explicit account-link and add-password flows should be validated too.

Email scope

  • Plan mailbox, alias, and forwarding workflows before launch.
  • Validate inbound delivery and forwarding verification if email is enabled.
  • Treat email checks as part of go-live, not a post-launch cleanup.

Validation Checklist

Before provisioning

  • Site setup is saved successfully in Client Portal.
  • Repository root contains build.yml.
  • ARTIFACT_DIR matches repo.artifactDirectory or repoBinding.artifactDirectory.
  • Browser clients use site-relative routes such as /admin/... and /data/....

After deployment

  • GET /admin/public/config returns the expected runtime bootstrap.
  • The chosen admin auth flow succeeds.
  • At least one critical /admin/data/* workflow succeeds.
  • GET /data/auth/config and GET /data/auth/methods return the expected runtime auth state.
  • At least one public and one authenticated /data/* operation succeed.
  • If Google sign-in is enabled, duplicate-prevention and explicit Google-link behavior match the product UX.
  • Email, mailbox, and forwarding checks pass for sites with email enabled.

Related Docs

  • Getting Started for the first-site path.
  • API for route-level request and response contracts.
  • Support for troubleshooting and escalation paths.