Migrate from Apifon to Twenty CRM

Apifon Contacts map to Twenty Persons. Phone number becomes the primary identifier (phoneNumbers field), email maps to email, name maps to displayName. Channel-specific consent flags (SMS opt-in, Viber opt-in, Email opt-in, RCS opt-in) from Apifon's metadata migrate as custom properties on the Person record. GDPR consent timestamps migrate as custom date fields. We use the email address as the dedupe key during import to prevent duplicate Person records.

Apifon Audience Lists map to Twenty Tags attached to the Person record. Each Audience List becomes a Tag with the list name as the tag name. List-level suppression rules (contacts blocked from sends) become custom boolean properties on the Person (e.g., suppress_sms, suppress_email) so that downstream automation does not silently re-import blocked contacts. We document which suppression rules existed per list during scoping.

Apifon Campaigns (message sends) map to Twenty Task records linked to the Person. The campaign name becomes the Task title, send status (delivered, failed, opened, clicked) becomes custom Task properties, and timestamp migrates as ActivityDate. Channel designation (SMS, Viber, Email, RCS) becomes a custom picklist field on the Task. We do not migrate message content unless the API exposes template body; we document which campaigns had custom content versus template-based sends.

Apifon automated flows with smart SMS failover map to documentation, not automated migration. Twenty has Sequences for task follow-ups but the trigger-based conditional routing in Apifon has no direct equivalent. We export flow structure, trigger conditions, and step sequences as a written document with screen-captured flow diagrams where available. The customer's team rebuilds flows manually in Twenty or via n8n integration post-migration.

Apifon message templates (SMS, Viber, Email, RCS) with variable placeholders migrate as content documentation. We export template body, channel designation, and variable placeholders. Twenty does not have a native template library for SMS or Viber; Email Templates exist for outbound emails. We document which templates map to Twenty Email Templates and which require rebuilding as separate channel integrations (Twilio for SMS, native Viber for messaging).

Apifon sign-up forms collect contacts and assign them to audiences with consent captured. The form structure, field mappings, and audience assignment rules migrate as written documentation. Form logic cannot be automated elsewhere without rebuilding. We deliver a field-map spreadsheet listing each form field, its Apifon data type, and the recommended Twenty Person field or custom property mapping.

Apifon campaign performance metrics (delivery rate, open rate, click rate, failure reason) migrate as custom properties on the linked Task records. Aggregate KPIs per campaign migrate as documentation noting total sends, delivery rate, and engagement rate. Individual event-level data (per-contact engagement timeline) migrates as separate Task records with event-type designation.

Apifon channel credentials (sender IDs, Viber business account IDs, RCS configuration identifiers) are platform-specific and tied to Apifon's carrier relationships. These cannot transfer to Twenty. We document which channels were configured per contact and flag the re-authentication steps required at each carrier or messaging provider (Twilio, Vonage, MessageBird) the customer selects for ongoing messaging after migration.

Apifon custom fields on Contacts extend the base schema with customer-specific properties. We export field names, data types, and all populated values. Custom fields migrate as Twenty custom fields on the Person object. Text fields map to text, number fields to number, date fields to date. Multi-select or tag-based custom fields in Apifon map to Twenty Tags attached to the Person. We pre-create the destination schema before any Person import.

If Apifon contains company-level records (business name, domain, address) linked to Contacts, these map to Twenty Companies. The company name becomes the Company displayName, domain maps to the website field, and address maps to address fields. Company records are created before Person import so that the Company-Person relationship is resolved at the moment of Person insert.