​

Superfície de Compatibilidade

Este projeto atualmente possui duas camadas de compatibilidade:

• aliases em staging sob /compat/* para iteração local
• caminhos legados no estilo Charles para testes de substituição direta (drop-in replacement)

​

Mutação de contato

​

Caminho em staging

• POST /compat/contact

​

Caminho legado

• PUT /api/v1beta/contact/

​

Notas

• os corpos de requisição preservam o formato de atualização de contato no estilo Charles
• external_reference_id, source_type e person_properties permanecem como campos de primeira classe
• o caminho legado retorna os campos status e message para corresponder às expectativas do sistema upstream

​

Disparo de jornada (journey trigger)

​

Caminho em staging

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

​

Caminhos legados

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

​

Notas

• os payloads permanecem centrados em número de telefone
• chaves de personalização arbitrárias são aceitas e repassadas para o payload do job enfileirado
• o caminho legado retorna status, message, triggerEventId e outboxJobId

​

Webhooks disparados por parceiros

​

Caminho legado

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

​

Notas

• tanto os estilos de payload de contato “flattened” (achatado) quanto “nested” (aninhado) são normalizados
• event_name é obrigatório e não pode conter espaços em branco
• quando configurado, EMARSYS_WEBHOOK_SECRET é imposto por meio do parâmetro de query secret
• respostas de sucesso retornam status, message, webhookEventId e outboxJobId

​

Postura de migração

Esta camada não pretende ser a arquitetura permanente. É a fronteira controlada que permite que o Twenty CRM e automações da era Charles migrem sem exigir reescritas simultâneas do sistema upstream.