Integration guide: how LaunchLayer connects to external services
A truthful map of what LaunchLayer reads, what it can write, what credentials are required, what still happens in the provider, and which integrations are production versus planned.
Integration rule
LaunchLayer does not treat every integration as equally automated. Each capability has its own account requirements, credentials, read/write scope, confirmation rules, verification steps, and provider-controlled limits. When provider state conflicts with LaunchLayer state, the provider is authoritative.
GitHub
Production wrapper/cloud-build workflows use the connected GitHub account and GitHub Actions for supported build and deployment jobs. LaunchLayer can create or use the configured private build repository and record workflow/run evidence. GitHub permissions, repository access, Actions availability, quotas, secrets, and runner behavior remain controlled by GitHub. Arbitrary GitHub Source Build V2 compilation is still planned; current V2 behavior is source inspection plus a deterministic readiness contract, not unrestricted customer-code execution.
Apple Developer and App Store Connect
Production Apple workflows support exact-app binding, credential validation, signed-IPA deployment, supported listing/localization/review-information updates, age rating, accessibility, TestFlight configuration, export compliance, availability, app settings, pricing, Apple IAP/subscription metadata, review submission, and release controls where the provider API supports them. Mutating operations require the configured App Store Connect credentials, exact app/version identity, explicit confirmation where applicable, and provider read-back or state verification. Apple controls processing, policy review, approval, and final provider state.
Google Play
Production Google workflows support matching Android artifact deployment plus supported listing text, contact details, supported images, Data Safety, tester groups, monetization catalog data, release tracks, and staged-rollout controls. These require the exact package/application binding and configured Google service-account access. LaunchLayer validates and commits supported provider edits, but Google controls processing, Play Console-only declarations, policy review, and final publication state.
RevenueCat and purchases
LaunchLayer currently provides monetization setup guidance, store-product synchronization/audit evidence, client-safe RevenueCat configuration checks, and a Purchase & Subscription Test Lab that records real Apple Sandbox/TestFlight or Google Play test outcomes. The separate hosted RevenueCat IAP manager for automatically managing RevenueCat products, entitlements, offerings, packages, webhooks, and synchronized customer state remains planned. A passing purchase must come from the real store test environment; LaunchLayer does not simulate one.
Push, Firebase, APNs and analytics
Native setup plans can describe dependencies, configuration, permissions, provider setup, and device tests. The managed Hosted Push Center using APNs/FCM and the provider-adapter Release Analytics capability are still planned. Do not interpret generated setup guidance as a production push backend or live crash/analytics connection. Post-Launch Health currently records dated evidence snapshots rather than claiming live telemetry.
Base44 and other app builders
LaunchLayer can accept supported Base44, React, Vite, and other web-app starting points through a live URL, GitHub repository, or source ZIP. A builder remains the owner of its own application runtime, backend, auth, database, and source. LaunchLayer wraps or prepares the release path; it does not automatically migrate or assume ownership of another platform's backend.
AI Project Agent
The Project Agent is an internal LaunchLayer integration layer rather than a third-party provider connection. It can read only the authenticated user's scoped project evidence through a server-side context broker and can prepare only allowlisted local-setting proposals. It cannot directly mutate credentials, signing, binaries, provider records, store review actions, or paid builds. Safe setting changes and the allowlisted stale local release-state repair require explicit approval and are revalidated before execution.
Credential handling
Credentials should be entered only through the designated secure LaunchLayer/provider fields, never pasted into the Project Agent chat, public support text, screenshots, or source control. LaunchLayer should expose non-secret readiness metadata where possible and fail closed when identity, signing, permission, or credential evidence does not match the intended app.
How to verify an integration
1) confirm the exact LaunchLayer project and app identity; 2) confirm the intended external account/team/application; 3) validate the credential or OAuth connection; 4) run the narrow supported read/preflight operation; 5) preview any mutation; 6) explicitly approve it; 7) read back provider state or durable LaunchLayer evidence; 8) keep the attempt in history rather than overwriting it; 9) test the released behavior on the real target environment when required.
Production versus planned
LaunchLayer marks capabilities independently. Hosted-wrapper builds, signed-binary deployment, Apple/Google publishing workflows, monetization sync audit, purchase test evidence, release monitoring, and the guarded Project Agent are implemented production capabilities as described in the app. Arbitrary Source Build V2 compilation, Hosted Push Center, the full hosted RevenueCat IAP manager, and live provider-adapter release analytics remain planned unless the capability registry is updated after verified release.