​

Superficie di compatibilità

Questo progetto attualmente supporta due livelli di compatibilità:

• alias staged sotto /compat/* per l’iterazione locale
• percorsi legacy in stile Charles per i test di sostituzione drop-in

​

Mutazione del contatto

​

Percorso staged

• POST /compat/contact

​

Percorso legacy

• PUT /api/v1beta/contact/

​

Note

• i corpi delle richieste mantengono la struttura di aggiornamento contatto in stile Charles
• external_reference_id, source_type e person_properties rimangono di prima classe
• il percorso legacy restituisce i campi status e message per corrispondere alle aspettative upstream

​

Trigger di journey

​

Percorso staged

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

​

Percorsi legacy

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

​

Note

• i payload rimangono centrati sul numero di telefono
• vengono accettate chiavi di personalizzazione arbitrarie e inoltrate nel payload del job accodato
• il percorso legacy restituisce status, message, triggerEventId e outboxJobId

​

Webhook attivati dai partner

​

Percorso legacy

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

​

Note

• vengono normalizzati sia gli stili di payload contatto appiattiti che quelli nidificati
• event_name è obbligatorio e non deve contenere spazi bianchi
• quando configurato, EMARSYS_WEBHOOK_SECRET viene applicato tramite il parametro di query secret
• le risposte di successo restituiscono status, message, webhookEventId e outboxJobId

​

Postura di migrazione

Questo livello non è pensato per essere l’architettura permanente. È il confine controllato che consente a Twenty CRM e alle automazioni dell’era Charles di migrare senza richiedere riscritture upstream simultanee.