Onboarding bridges: drop Winnow into your stack without rewriting your call sites

We just shipped a complete onboarding-bridges layer: 23 sources at beta as of today, covering the SDKs your team already uses for feature flags, LLM observability, and analytics. The bar for adopting Winnow is now "swap one import" for most paths, and "register a bridge with a JSONL export" for the rest. No SDK rewrites. No giant migration projects.

What "23 sources at beta" actually means

Every source listed here passes the same beta bar: the stated surface works against a live backend, the documented call sites have a wired data path, an operator can invoke the import or trace flow, and at least one customer-shaped end-to-end smoke is recorded in our validation folder.

Category	Source	Primitive
Feature flags	LaunchDarkly	shim + importer
Feature flags	Statsig	shim + importer
Feature flags	Eppo	shim + importer
Feature flags	GrowthBook	shim + importer
Feature flags	Optimizely FX	shim + importer
Feature flags	Amplitude Experiment	shim + importer
Standards	OpenFeature provider	provider plugin
LLM observability	LangSmith	shim + importer
LLM observability	Braintrust	shim + importer
LLM observability	W&B Weave	shim + importer
LLM observability	Langfuse	importer + OTel ingest
LLM observability	Phoenix / Arize AX	importer + OTel ingest
LLM observability	Helicone	shim
Web analytics	Adobe Analytics	importer
Web analytics	GA4	importer

The seven OpenTelemetry vendor namespaces (OpenInference, Vercel AI SDK, MLflow, Traceloop, Langfuse, Weave, Braintrust) also stream live into Winnow through the Phase 1 substrate at POST /api/v1/otel/v1/traces, so the practical surface is wider than this table suggests.

Four primitives, ranked by switching cost

Most customers want the cheapest path. We ship four:

SDK-compat shim. You keep your existing code. You swap from launchdarkly import ... for from sdk.compat.launchdarkly import .... Every call site stays. We route evaluation through Winnow's engine; events fire through a shared POST /api/v1/bridge/events route. The cost is one line per import.

OpenFeature provider. Want your code to be vendor-neutral? Register Winnow as your OpenFeature provider. Now client.get_boolean_value("flag-a", False, ctx) is portable across every OpenFeature-shaped vendor. Cost is one registration call.

OTel ingest. Already emitting OpenTelemetry from your LLM application? Point your OTLP exporter at Winnow. We map nine vendor namespaces to a canonical schema automatically. Cost is one env var (OTEL_EXPORTER_OTLP_ENDPOINT).

REST + warehouse importer. Backfilling history? Export your existing tool's data as JSONL, point the importer at it, run the operator endpoint. We persist a cursor, so re-running on a fresh export is a no-op for already-imported rows. Cost is one curl.

What it looks like in practice

A LaunchDarkly customer who wants to start observing in Winnow today:

# Before
from ldclient import LDClient, Context
client = LDClient(sdk_key="...")
client.track("trial-started", Context.create("u-1"), 99.99)

# After
from sdk.compat.launchdarkly import LDClient, Context
client = LDClient(sdk_key="<winnow key>")
client.track("trial-started", Context.create("u-1"), 99.99)

That is the entire migration for the live path. The track call now fires a fire-and-forget POST to Winnow's /api/v1/bridge/events. The customer's existing variation, variation_detail, bool_variation, etc. all keep working.

For backfilling the last three months of evaluation history, the same customer runs:

curl -sS -X POST http://localhost:8000/api/v1/integrations \
  -H "Content-Type: application/json" \
  -d '{"type":"bridge","config":{"source":"launchdarkly","path":"./ld-eval-export.jsonl","experiment_id":"backfill","arm_id":"control"},"enabled":true}'
# returns {integration_id}

curl -sS -X POST http://localhost:8000/api/v1/integrations/<id>/run
# returns {accepted, skipped, cursor}

Cursor-aware re-runs handle ongoing side-by-side periods automatically.

What we did NOT ship

Honesty matters here. The following are still planned, not beta:

• Humanloop zip-export importer (zip extraction is its own shape).
• Vellum YAML workflow compiler (workflow-import is a different paradigm).
• JS and Go bindings for the shims (Python only at beta).
• Live REST walkers for the flag-platform importers (JSONL bulk export is the supported path; the walkers land if customer signal warrants).
• The full LangSmith / Braintrust / Weave dataset / eval surface. The tracing decorators and wrap_openai are wired; Client().create_dataset() etc. raise NotImplementedError with a pointer to the JSONL importer cookbook.

None of those gaps block a migration. They are features we will wire when a customer needs them.

Per-source cookbooks

Every source has a copy-pasteable migration recipe at docs/cookbook/migrate-from-<source>.md (24 of them today). Each one walks the swap, the initialize, the probe, and the cleanup. The validation folder has matching cowork scripts so you can verify end-to-end before you change a single production line.

Try it

If you are already on Winnow, the new shims and importers are on main. Pick a source, find the cookbook, swap the import. The side-by-side period is built in: both your old tool and Winnow can run in parallel until you cut over.

If you are not on Winnow yet, this is the cheapest moment to start. The four primitives mean you do not need a green-field project to evaluate us; you can run Winnow in observe-only mode against your existing call sites and see whether our experimentation engine surfaces signal you were missing.

The next steps for us: shipping the JS bindings, wiring the live REST walkers, and getting Humanloop + Vellum across the line. The next steps for you, if you want them, are in the cookbooks.