Skip to main content
Open Settings → Workspace → Data migration to connect a Famulor 1.0 account with its API key. The key is used only while the preview or import request is running. It is never stored, logged, cached, or returned. Alternatively, ask Milian to “move my assistants from Famulor 1.0”. Milian shows a secure authorization card. After you click Authorize Famulor 1.0, the Famulor 1.0 OAuth page opens and returns to the same Milian conversation. Milian then:
  1. reads the available migration tools through the Famulor 1.0 MCP endpoint,
  2. previews assistants, automations, campaigns, tools, and knowledge bases,
  3. asks whether to migrate everything or selected source IDs/names and whether to include all related tools and knowledge bases, and
  4. imports only the confirmed selection.
The OAuth access and refresh tokens are encrypted, workspace-scoped, and renewed server-side. They are never included in the Milian conversation.

​
Log in with your Famulor 1.0 account

If you already have a Famulor 1.0 account, you can log in directly on this platform’s main domain using your old email and password — no separate sign-up needed. On first login, a matching account is created here automatically (a platform-root workspace). After that, one-click migration no longer requires pasting an API key: open Settings → Workspace → Data migration and click Connect with my Famulor 1.0 account on the Connect step. It runs the same preview and import as the API-key flow, just authenticated through your login instead of a pasted key.
Platform admins enable this login bridge by setting the FAMULOR_V1_WHITELABEL_ADMIN_KEY environment variable to the white-label admin API key of app.famulor.de. This key stays server-side and is never exposed to the client. Without it, the bridge is disabled and the Connect step falls back to the API-key flow only. The bridge only works on the platform’s main domain — never on white-label reseller domains — answers neutrally on any failure (it never reveals whether an account exists on either platform), and is rate-limited.
  • Famulor 1.0 built-in tools are read from each assistant, created as separate entries in the central Tools library, and assigned only to that source assistant. This includes end call, cold/warm transfer, DTMF/keypad collection, and assistant transfer. Assistant-transfer targets are resolved after all selected assistants have been created, so forward references are preserved. DTMF and keypad collection are flow-only on the new platform: the migration creates and assigns them, but you must place the matching DTMF or Collect node in Flow Builder before they execute.
  • Selected custom HTTP mid-call tools are also created in the central Tools library. The Famulor 1.0 read API returns these tools account-wide without their tool_ids assistant links, so every selected custom tool is assigned to every assistant imported in the same run.
  • A calendar_integration with usable Cal.com credentials (an API key and an event type ID) becomes a native calendar integration and is assigned to its source assistant instead of being duplicated as a built-in tool. Calendar entries for other providers (for example Calendly) or Cal.com entries missing usable credentials are not imported — reconnect that calendar manually under Integrations after import. Calendly itself is natively supported on the new platform via its own OAuth connection, so reconnecting it does not require an API key.
  • Selected knowledge-base shells are created before assistants. If an assistant references one of those selected knowledge bases, the new knowledge-base ID is written to that assistant automatically. Famulor 1.0 does not expose the document bodies, so documents still need to be added again.
  • Famulor 1.0 dualplex assistants are imported in Half-cascade mode.
  • The preview lists each assistant’s individual built-in tool configurations (call transfer, DTMF, end call, and so on) in its details, so you can review exactly what will be created before importing.
If the source account’s plan does not include automations, the source API may return HTTP 403 for only that resource family. Preview and import skip automations in that case and continue with all other selected resources.
The canonical callback uses NEXT_PUBLIC_APP_DOMAIN (for example app.famulor.io). You can override it with FAMULOR_V1_OAUTH_REDIRECT_BASE_URL=https://app.famulor.io. Allowlist that origin in the Famulor 1.0 OAuth server. The callback returns to the original whitelabel conversation after the canonical exchange.
  1. Generate the preview and review every warning.
  2. Import assistants before campaigns and automations so their bindings can be restored in the same run.
  3. Reconnect phone numbers, messaging senders, approved WhatsApp templates, calendars (any provider other than Cal.com, and Cal.com entries that had no usable credentials), and knowledge-base documents on the new platform.
  4. Open every imported campaign and automation, repair review items, test it, and activate it manually.
Voice campaigns keep their assistant, timezone, daily/overnight windows, concurrency, retry policy, and goal settings when those resources can be resolved. Scheduled or running source campaigns are always reset to drafts. WhatsApp and SMS campaigns remain unimportable until their target sender, template, or sending number has been connected because Famulor 1.0 resource IDs are not portable. The source campaign endpoint does not expose its audience, so leads must be imported or assigned separately. Automations are always created as disabled drafts. Native mappings cover assistant-event, webhook, schedule and manual triggers plus HTTP, webhook response, delay, SMS, outbound-call, contact-upsert, and workspace-email steps. Unsupported integrations and legacy code are preserved as visible review nodes instead of being silently dropped or executed.

​
REST API and MCP

Use POST /api/v1/migrations/famulor with action: "preview" first, then send action: "import" with the exact selected source IDs. The target API key needs read permission for preview and the matching write scope for every selected resource family. The API-key flow is available as the MCP tools preview_famulor_1_migration and import_famulor_1_data. REST is recommended for unattended bulk migration. Milian uses the source MCP OAuth connection instead of asking for a source credential, while still running the same deterministic mapping and draft-safety rules.
The Famulor 1.0 MCP endpoint uses its own OAuth flow. A Famulor 1.0 REST API key does not authenticate that MCP endpoint. Never paste an API key into a Milian conversation; use the authorization card.