Quick answer: Devotel Orbit's import wizard now covers Klaviyo — the lifecycle-marketing surface our migration buyers arrive from most often. Open /import/klaviyo, paste a Klaviyo private API key, and the wizard walks you through five steps: connect, pick the entities to move, set a per-kind conflict policy, review a dry-run with counts and conflicts, then run the job with live progress. Klaviyo lists become Orbit segments, templates become Orbit message templates, flows become Orbit journeys, and profiles become Orbit contacts. The wizard is read-only against your Klaviyo account — nothing outbound ever sends through Klaviyo, and the private key is encrypted on submit and wiped when the run finishes.
What the wizard imports
The Klaviyo importer moves five entity kinds, in a dependency order the wizard sets for you — audiences before the profiles that reference them, flows last:
- Lists → segments. Klaviyo's static audiences arrive as Orbit segments, preserving membership.
- Segments → segments. Klaviyo's dynamic, rule-based audiences arrive as Orbit segments with their definitions preserved, so a behavioral segment keeps evaluating after the move.
- Templates → message templates. Email and SMS templates map onto Orbit's message-template surface, ready to reference from campaigns.
- Flows → journeys. Klaviyo automations arrive as Orbit journeys with their trigger and step structure intact — the mapping notes below cover the trigger translation.
- Profiles → contacts. Klaviyo profiles arrive as Orbit contacts with email, phone, and custom properties.
Every kind is optional on the pick step — you can move audiences only and rebuild templates by hand if that is how you want to sequence the cutover.
The five steps
The wizard is one page, and each step is reachable by refresh or browser-back because the step, the encrypted credential envelope, and the job id live in the URL.
- Connect. Paste a Klaviyo private API key (the
pk_…key from Settings → API keys in Klaviyo). Klaviyo does not publish an OAuth Connect surface for third-party account delegation, so the wizard reads your account with a key. A read-only scope is sufficient. The key is encrypted before it leaves the page, and an optional account label is display-only — it never authenticates anything. - Pick. Check the entity kinds to move — lists, segments, templates, flows, profiles, all pre-selected by default.
- Map. Klaviyo's API does not expose an account-user roster, so there is no teammate mapping table — imported rows stay owned by you and can be reassigned per entity afterward. This step is where you set the conflict policy, covered next.
- Dry-run. The wizard previews counts per entity, an estimated runtime, and the number of known conflicts against rows that already exist in Orbit. Nothing is written on this step, and you can refresh the counts if your Klaviyo account is still changing.
- Run. The job streams per-entity progress live — imported, skipped, failed — with a cancel control mid-flight and a reconcile table on success. A "Go to your inbox" CTA takes you to the migrated contacts. When the run reaches a terminal state, the wizard also offers a rollback that deletes the contacts that specific job created.
After onboarding, every job — including this one — is durable under Settings → Migrations: status, failure reasons, cancel, and rollback all live there, not only in the wizard.
Conflict policy per kind
Entities that already exist in Orbit collide with incoming rows, so the wizard asks, per kind, what to do on a conflict:
- Lists, segments, profiles: skip (the default), overwrite the Orbit row, or merge fields.
- Templates: skip or overwrite — merge does not apply to template bodies.
The default is skip everywhere. Overwrite or merge is a deliberate choice per kind, and the dry-run count of known conflicts tells you how many rows the policy will actually touch before you commit.
Two mapping notes worth stating plainly. First, there is no teammate roster to map — Klaviyo's API does not expose one, so ownership stays with you post-import. Second, flows arrive with their trigger and step structure as Orbit journeys; the flow trigger mapping is preserved structurally, and you review the journey on Orbit before switching it on, because a journey that was live on Klaviyo is not automatically live on Orbit.
Why outbound never touches Klaviyo
The importer is read-only against your Klaviyo account — it maps configuration and audience, and that is all. Outbound messages you send from Orbit exit via Devotel Orbit's own messaging infrastructure; the legacy Klaviyo credentials you paste into the wizard are never used to originate a call or a message. The Klaviyo account keeps serving its own traffic in parallel until you cut over; the import does not interrupt it, and the credential is wiped from Orbit's side when the run succeeds or is cancelled.
Safety: how the manual-credential flow is built
Because Klaviyo has no OAuth Connect surface, the wizard runs a manual-credential flow instead of a redirect: your private key is submitted with read-only scope, encrypted before transit, and validated against Klaviyo before a single entity is read. If validation fails, the wizard surfaces a bounded, redacted error and a retry — never raw provider output. While a run is in progress, the live progress stream and the status polling both have explicit retry-and-recover behavior on the page, so a flaky connection shows a banner with a retry instead of a frozen spinner.
First-run checklist
Tied to the canonical operational guide — run a platform migration end-to-end — a first Klaviyo-to-Orbit run looks like this:
- In Klaviyo, create a private API key with read-only scope; label it for the migration so rotating it later is unambiguous.
- Open
/import/klaviyoon Orbit, paste the key, and confirm the account label in the header matches the account you meant. - Select all five entity kinds, or trim to the ones you want moved in this pass.
- Leave every conflict policy on skip for the first run unless you already know which Orbit rows you intend to replace.
- Read the dry-run table: check the upstream counts against your Klaviyo account's own audience sizes, and look at the known-conflict count before starting the real run.
- Start the import and stay on the run step until the first per-entity progress ticks arrive — then you can leave; the job continues server-side and is listed under Settings → Migrations.
- On success, spot-check a migrated segment's membership and one imported journey's trigger before rebuilding any sending campaign on top of the new rows.
- If the run moved the wrong rows, use the wizard's rollback — it deletes exactly the contacts that job created and nothing else — then rerun with the corrected scope or policy.
Frequently asked questions
Does the import interrupt my live Klaviyo account?
No. The wizard is read-only against Klaviyo. Your lists, flows, and sends on Klaviyo keep running; you cut over by starting to send from Orbit, not by the import flipping anything on the Klaviyo side.
Will my Klaviyo flows start sending on Orbit as soon as they are imported?
No. Flows arrive as Orbit journeys with their trigger and step structure, and a journey is not live until you switch it on in Orbit. Review each imported journey before enabling it.
What happens to my Klaviyo API key?
It is encrypted on submit, used only to read your account during the migration, and wiped from Orbit when the run finishes — whether it succeeds, fails, or is cancelled.
Can I undo an import?
Yes. Both the wizard and Settings → Migrations offer a rollback per job. Rollback deletes the contacts created by that specific job; contacts you added through any other path are untouched.
Which Klaviyo API scopes does the import need?
Read-only scope is sufficient — the importer never writes to your Klaviyo account.