Step della sequenza

Step SEND_EMAIL e WAIT, ritardi, regole di attivazione e modifica solo in DRAFT.

Una sequenza si costruisce con step ordinati. Esistono solo due tipi di step e puoi modificarli solo mentre la sequenza e in DRAFT.

Tipi di step

`stepType`	Cosa fa	Campi che usa
`SEND_EMAIL`	Invia un'email	`templateVersionId` (una versione PUBLISHED), `subject` opzionale
`WAIT`	Attende prima dello step successivo	`delayMinutes` (>= 1)

Gli step sono ordinati per position (intero >= 0).

Aggiungere uno step

POST /sequences/{id}/steps
Authorization: Bearer <apiKey o accessToken>
X-Tenant-Id: {tenantId}
Content-Type: application/json

{
  "stepType": "SEND_EMAIL",
  "position": 0,
  "templateVersionId": "ver_123"
}

Campo	Obbligatorio	Note
`stepType`	Si	`SEND_EMAIL` o `WAIT`
`position`	No	Ordine dello step (intero >= 0)
`delayMinutes`	Solo `WAIT`	Minuti di attesa (>= 1)
`templateVersionId`	Solo `SEND_EMAIL`	Versione di template in stato `PUBLISHED`
`subject`	No	Sovrascrive l'oggetto (fino a 998 caratteri)

Uno step WAIT di 1440 minuti attende un giorno prima dell'invio successivo:

{
  "stepType": "WAIT",
  "position": 1,
  "delayMinutes": 1440
}

Endpoint degli step

Metodo	Percorso	Scope	Descrizione
`POST`	`/sequences/:id/steps`	`sequences:write`	Aggiungi step (solo `DRAFT`)
`PATCH`	`/sequences/:id/steps/:stepId`	`sequences:write`	Modifica step (solo `DRAFT`)
`DELETE`	`/sequences/:id/steps/:stepId`	`sequences:write`	Elimina step (solo `DRAFT`)

Regole di attivazione

La chiamata a POST /sequences/:id/activate valida la catena di step. Deve avere:

Almeno uno step.
Almeno uno step SEND_EMAIL (una sequenza di sole attese non invia nulla).
Mai due WAIT consecutivi — unisci le attese in un unico step.

Se la catena non e valida, l'attivazione fallisce e la sequenza resta in DRAFT.

Come vengono eseguiti i ritardi

Il motore raggruppa le attese: quando un invio termina cerca il successivo SEND_EMAIL, somma i delayMinutes degli step WAIT intermedi e pianifica un job differito in BullMQ (delayMs = delayMinutes * 60000). Ogni job e idempotente, con retry e backoff esponenziale, quindi un retry non duplica mai un invio. L'email esce dal pipeline normale — con soppressioni e quota applicate, e routing di lingua per contatto.