Skip to content
Launch Rail
Integration architecture

Keep your providers. Give them one coherent product layer.

Launch Rail separates durable product workflows from provider-specific APIs. Adopt the interfaces and adapters that match your deployment, then extend the source when your stack requires something specific.

Provider boundaries

Integrate around the workflows your product owns.

Provider names below illustrate supported integration categories and common scoping targets. Exact adapter availability, version, and deployment support are confirmed in the technical review.

Identity providers

Keep company, membership, and session domain logic in Launch Rail while connecting the identity provider selected for the customer deployment.

  • OIDC providers
  • SAML providers
  • Directory provisioning

Delivery providers

Notifications centralizes templates, preferences, routing, retries, and delivery history while provider adapters handle external delivery APIs.

  • Email
  • SMS
  • Mobile push
  • Team channels

Object storage

Media workflows separate product metadata and policy from customer-owned object storage. Confirm the adapter and cloud target during technical scoping.

  • AWS S3
  • S3-compatible storage
  • GCS target

Billing systems

Entitlements can consume plan and subscription state from a mature billing provider. The separate Payments module remains planned and demand-gated.

  • Stripe
  • Paddle
  • Existing billing stack

Observability

Shared OpenTelemetry conventions make it possible to route service telemetry into the monitoring platform operated in the customer environment.

  • OTLP collectors
  • Grafana
  • Datadog
  • Self-hosted stacks

Automation and events

Versioned events and outbound delivery patterns connect product operations to internal consumers, automation tools, and customer endpoints.

  • Webhooks
  • NATS
  • CloudEvents
  • Workflow platforms

Open interface model

Different consumers, explicit access paths.

Published per available service

REST and Connect/gRPC

Application and service clients use documented contracts. Check each registry entry for its current documentation and API-reference availability.

Workflow-specific

Events and webhooks

Event shapes and delivery behavior are part of the service contract, not a claim that every module emits the same event set.

Pilot

MCP via Agent Gateway

Selected tools are exposed through tenant-scoped policy, authorization checks, budgets, expiry, approvals for sensitive writes, and audit events.

The integration remains part of your system.

You receive source and deployment artifacts under the agreed license. Provider credentials stay in your environment, and custom adapters can follow the same contracts as the supplied integration path.

01

Confirm provider and API version

02

Define secrets and network boundaries

03

Map retries, idempotency, and failure handling

04

Test the adapter in the customer deployment

05

Record ownership and upgrade compatibility