Investor brief · MuleSoft integration
Pause-Health.ai's integration with JupyterHealth, DBDP wearable features, Agentforce, and consumer wearables is designed to run through MuleSoft Anypoint — the connectivity platform most US health systems and large payers already license. Today a Mule app is live on CloudHub 2.0 with Flex Gateway enforcing JWT validation and rate limiting; the full three-tier architecture activates with the first design partner.
API-Led Connectivity, applied to menopause
Pills: Wired in prototype wired in the prototype today · Designed design decision, activates with the first design partner.
Wrap each upstream once
Per-vendor adapters that will own OAuth, rate limits, retry, and circuit-breaker behavior. One System API per wearable (Oura, Apple Health, Whoop, Empatica) plus one each for JupyterHealth Exchange and the DBDP feature worker. Today the equivalent logic lives in the Python pause_ingest package, not in Mule.
Orchestrate cross-system flows
Stateless orchestration between System APIs. pause-ingest-process-api will validate an Open mHealth payload, transform to FHIR R5 via DataWeave, post to JHE, and fire a feature compute request to DBDP. Reference XML + DataWeave committed under mulesoft/; not yet deployed to an Anypoint runtime.
Pause-facing read endpoints
Read-optimized FHIR Bundles that combine raw Observations with DBDP-computed feature Observations. The Pause clinician web app calls these — never JHE or DBDP directly. Today /health and /providers are live on CloudHub 2.0, protected by Flex Gateway (JWT Validation + Rate Limiting); /timeline and /intake are deterministic mocks at /api/mulesoft/* with the same response shapes. Full three-tier deployment activates with the first design partner.
Why MuleSoft
Most US health systems and large payers already license MuleSoft Anypoint Platform. Adding Pause becomes 'another Mule app on the existing fabric' — the lowest-friction posture a procurement team can encounter. This is the GTM thesis; the first Mule-on-customer-Anypoint deployment lands with the first design partner.
Adding a new wearable (Garmin, Withings, etc.) will be one new System API plus one row in the Process API's routing config. The Pause backend would be untouched. Customers would extend the integration without coordinating with our engineering team. Operationalizes when Mule is deployed in a customer org.
The customer's integration team will own the System and Process APIs. Pause will own the Experience APIs and the menopause-specific logic. Each side operates the layer they understand best. Honest framing: this is a design intent until there is a customer to own the customer half.
MuleSoft in the middle, JupyterHealth + FHIR on the back, DBDP for wearable features, Agentforce on the front. Each piece is the best-in-class substrate for its job, and the composition is already visible in the prototype: the Care Router's grounding card cites the mocked Experience API as one of its federated sources (see /demo/intake).
Touch the architecture
/health and /providers proxy through Flex Gateway to a real Mule app on CloudHub 2.0 — JWT-validated, rate-limited, OAS 3.0 spec in Anypoint Exchange. /timeline and /intake are deterministic mocks with the same response shapes. The data lineage on the timeline endpoint is intact: every DBDP-computed feature Observation carries a derivedFrom reference back to the raw window it was derived from.
/api/mulesoft/health and /api/mulesoft/providers proxy through Flex Gateway (JWT Validation + Rate Limiting, 10 req/min) to a Mule app on CloudHub 2.0 (iterations 1–7). Any non-2xx degrades gracefully to the deterministic mock; meta._source flips between "live-mulesoft" and "mock-fallback". Governance policy stack and OAS 3.0 spec live in Anypoint Exchange — see docs/MULESOFT_API_MANAGER_RUNBOOK.md.Prototype vs production
| Aspect | Prototype today | Customer deployment |
|---|---|---|
| Where the integration runs | /health and /providers proxied through Flex Gateway → CloudHub 2.0 worker (live, JWT-enforced). /timeline and /intake served as deterministic mocks by Next.js. | Three-tier Mule application on the customer's Anypoint Runtime Fabric or CloudHub 2.0. |
| Reference flow code | mulesoft/flows/pause-process-api.example.xml — labeled Mule 4 XML with comments; not deployable. | Real Mule project with property files, secret references, API spec in Anypoint Exchange, CI/CD. |
| OMH → FHIR transform | Shipped 2026-06-26 as pause-omh-to-fhir-library v1.0.0 on Anypoint Exchange. CloudHub worker (1.0.5) consumes it as a Maven dependency at dw::pause::health::omh. | Same shared Exchange asset, reused unchanged across customer Mule apps and a future pause-ingest-process-api. |
| Wearable vendor adapters | Direct vendor calls from pause_ingest (Python). | Per-vendor System APIs in Mule with token vaults, rate-limit controls, circuit breakers. |
| Pause backend integration surface | Direct calls to JupyterHealth Exchange (where wired) or to the mocked Experience APIs. | Calls go only to Experience APIs. The customer's IT team owns the policy on those endpoints. |
Phased plan
Today
Reference Mule flow + DataWeave transform committed under mulesoft/. Four mocked Experience APIs at /api/mulesoft/*. Design doc at docs/mulesoft-integration.md. Investor page (this one).
Complete · 2026-06-09
Seven iterations shipped: CloudHub 2.0 worker live with /health + /providers (iterations 1–2); Flex Gateway (Docker + ngrok) with runtime enforcement (iteration 3); Rate Limiting SLA 10 req/min (iteration 4); OAS 3.0 spec published to Anypoint Exchange as pause-provider-experience-api-spec v1.0.2 (iteration 5); static ngrok domain pinned (iteration 6); JWT Validation via Auth0 RS256/JWKS replaces Client ID Enforcement, plain Rate Limiting replaces SLA-based, Next.js proxy fetches Auth0 M2M tokens automatically (iteration 7). Current policy stack: JWT Validation + Rate Limiting (10 req/min global). Next: persistent VM to host the gateway (iteration 8).
4–6 weeks with first design partner
Deploy Mule apps into the customer's Runtime Fabric. Wire their identity provider (PingFederate / Azure AD) to the Experience APIs. Cut over the Pause backend's reads.
Started · 2026-06-26
Nine shared artifacts on Anypoint Exchange under the Pause Health business group. One end-to-end consumed library — pause-omh-to-fhir-library v1.0.0 (CloudHub worker 1.0.5 consumes it as a Maven dependency). Five per-wearable System API specs covering both architectural patterns: pull-from-vendor for pause-oura-system-api-spec (the template) + pause-whoop-system-api-spec + pause-garmin-system-api-spec (OAuth 1.0a upstream), and upload-to-Pause for pause-healthkit-system-api-spec (iOS app posts HealthKit batches) + pause-empatica-system-api-spec (researcher uploads E4 .zip archives). Plus two infrastructure System APIs (pause-jhe-system-api-spec, pause-dbdp-system-api-spec) and the Process tier (pause-ingest-process-api-spec) that ties them together. With the Process tier published, the full MuleSoft API-led three-tier story is on Exchange (System + Process + Experience). The eight spec-tier assets are contract-only — implementations are gated on Phase 1c (real Mule projects wrapping the existing pause_ingest Python layer); pause_ingest does the equivalent orchestration in-process today.
Why investors should care
Read deeper
Continuing the investor brief