​

Compatibility Surface

This project currently carries two compatibility layers:

• staged aliases under /compat/* for local iteration
• Charles-style legacy paths for drop-in replacement testing

​

Contact mutation

​

Staged path

• POST /compat/contact

​

Legacy path

• PUT /api/v1beta/contact/

​

Notes

• request bodies preserve the Charles-style contact update shape
• external_reference_id, source_type, and person_properties remain first-class
• the legacy path returns status and message fields to match upstream expectations

​

Journey trigger

​

Staged path

• POST /compat/journey-trigger/{legacyPath}

​

Legacy paths

• POST /webhooks/v0/rest-trigger/organization/{organizationId}/flow/{flowId}/trigger/
• POST /webhooks/v0/rest-trigger/organization/{organizationId}/flow/{flowId}/trigger/{triggerId}/

​

Notes

• payloads remain phone-number centric
• arbitrary personalization keys are accepted and forwarded into the queued job payload
• the legacy path returns status, message, triggerEventId, and outboxJobId

​

Partner-triggered webhooks

​

Legacy path

• POST /api/v0/webhooks/incoming/emarsys/custom_external_event

​

Notes

• both flattened and nested contact payload styles are normalized
• event_name is required and must not contain whitespace
• when configured, EMARSYS_WEBHOOK_SECRET is enforced through the secret query parameter
• successful responses return status, message, webhookEventId, and outboxJobId

​

Migration posture

This layer is not meant to be the permanent architecture. It is the controlled boundary that lets Twenty CRM and Charles-era automations migrate without requiring simultaneous upstream rewrites.