Trust boundary · Integrations

Integrations

Local adapter contract only. Confirmed means the controlled contract passed; it is not provider acceptance, paid or settled. Live posting, payment and refunds are disabled.

Module proof path

Integrations connects API boundaries to public proof.

See the workflow, proof, and operating limits in one scan before reviewing the detailed path.

Inspect proof Open demo

Scope

Who needs the workflow, what is visible, and what stays out.

Proof

Screenshot, proof card, or demo path that makes the claim inspectable.

Boundary

What requires human review or source evidence.

Why this page is short

This page only publishes the boundary buyers should rely on.

Some areas are intentionally represented by a narrow public boundary instead of a full feature page. That keeps sensitive operations, access rules, and unfinished marketing claims out of the buyer-facing experience.

How we evidence this

Enforced boundary

What the Integrations module refuses to do.

All module boundaries

Local adapter contract only. Confirmed means the controlled contract passed; it is not provider acceptance, paid or settled. Live posting, payment and refunds are disabled.
BOUNDARY · apps/api/src/ironbound_api/modules/integrations/accounting_contracts.py:7

1 further boundary constant in this module

Integration records are provider-neutral, account-scoped, and audit-ready. Credentials and private calendar URLs are accepted only through write-only setup, are never returned, and belong only in the server-side vault. Calendar reads store busy windows only. No scraping, payment movement, tax filing, private event detail, or unreviewed external write is performed by these endpoints.
INTEGRATION_BOUNDARY · apps/api/src/ironbound_api/modules/integrations/router.py:136

Copied verbatim from apps/api/src/ironbound_api/modules/integrations/router.py and regenerated from apps/api/src/ironbound_api/modules. The API returns these same strings in its boundary fields, and a drift check fails the build if this page and the source stop agreeing.

Pilot access

Show the platform through one real operating story.

The best demo is not a feature checklist. It follows a request from owner intake to manager triage, vendor packet, field evidence, reviewed closeout, and owner-safe reporting.

Recommended demo path

Owner submits a winter maintenance concern.
Manager reviews urgency, access, and authority.
Vendor receives only the package-local scope.
Field evidence becomes a reviewed owner update.

Request a guided demo

We respond with the recommended demo route, who should attend, and what production access would require.