Migrating from 2-way to Platform Linking
Why we stopped doing bidirectional integrations and how to move to one-direction Platform Linking.
Migrating from 2-way to Platform Linking
For years, CHeKT and its biggest partners ran two-way integrations. CHeKT called the partner's APIs; the partner called ours; both sides kept state in sync. It worked, until it didn't.
This guide explains why every integration today is external → CHeKT (Partner API + webhooks) and what the migration path looks like for older two-way integrations.
The problem with two-way
- Drift. Two systems holding the same state always disagree at some point. Resolution is expensive.
- Coupling. A change on either side breaks the other. Coordination kills speed.
- Auth complexity. Two sets of keys, two webhooks, two retry policies, double the failure modes.
- Onboarding cost. Every new partner becomes a custom project. The marginal cost never drops.
The new model
We split integrations into two patterns. Both flow in the same direction — into CHeKT — but hit different API surfaces:
| Pattern | Direction | API surface | Auth |
|---|---|---|---|
| CHeKT Apps | Third-party → CHeKT | Public API | API Key |
| Platform Linking | Partner platform → CHeKT | Partner API | API Key → OAuth → Assertion Token |
If you find yourself building outbound calls from CHeKT into your platform, stop. CHeKT exposes events over webhooks and data over the Partner API — your side consumes both.
Migration steps for existing two-way partners
Step 1 — Confirm CHeKT is the source of truth for operational data
Events, alarms, dispatches, and audit logs live in CHeKT. Drop any code on your side that pushes those into CHeKT — it's no longer needed.
Anything your platform owns (video, panel configuration, your own UI state) stays on your side. CHeKT will not call out to fetch it.
Step 2 — Pick the right auth tier
- API Key — stable, server-to-server, low ceremony. Best starting point.
- OAuth 2.0 — user-mediated grants on your platform's users. Use when the integration is per-user, not per-platform.
- Assertion Tokens — signed JWTs with rotating keys. Strictest trust tier; reserve for high-volume, high-stakes service-to-service.
Step 3 — Subscribe to webhooks instead of polling
Anywhere your old code polled CHeKT on a timer, replace it with a webhook subscription. Less load, lower latency, fewer surprises during traffic spikes.
Step 4 — Retire CHeKT's old outbound endpoints into your service
Once your side is calling the Partner API for enrichment and consuming events via webhooks, the legacy outbound path from CHeKT into your platform can be decommissioned. Less code is less to break.
What we learned
The biggest lesson: direction matters more than features. A clean one-direction integration with fewer features ships faster, breaks less, and onboards new partners in days, not quarters.