Come faccio a sapere quando qualcosa è terminato?

In due modi, e puoi usare l'uno o l'altro. Il polling è descritto sotto e funziona sempre. Una callback di solito è meglio, se puoi accettare una richiesta in ingresso: imposta callbackUrl (in signature per un flusso, in settings per una busta) e te lo diciamo noi; conta soprattutto su una piattaforma con un budget giornaliero di chiamate: una busta lasciata aperta tre giorni, interrogata ogni cinque minuti, costa circa 860 chiamate per non sapere nulla 859 volte. Se il tuo ricevitore vuole che ci autentichiamo (un token, una chiave API, OAuth2 come fa Salesforce), configura un ambiente di callback e invia {"env": "prod", "onSuccess": "/hooks/ok"}. Per sapere anche quando un firmatario viene sostituito, aggiungi l'indirizzo facoltativo onEvent: riceve recipient.replaced, mentre onSuccess e onError continuano a dire soltanto come si è conclusa la richiesta (dettagli).

Per il polling, chiedi GET /api/v1/flow/{flowId} (oppure GET /api/v1/sign/envelopes/{id} se hai usato il percorso in due passaggi) e decidi in base a output.status, non in base alla specifica stringa di stato:

curl https://your-host/api/v1/flow/FLOW_ID \
  -H "Authorization: Bearer YOUR_API_KEY"
{ "output": { "status": "pending",
              "flow": { "status": "awaiting_signature", "closed": false },
              "...": "..." } }

"status": "pending" significa: continua a chiedere. "succeeded" e "failed" significano entrambi: fermati. Insieme coprono tutti i modi in cui un flusso smette di cambiare — signed, declined, expired, cancelled — quindi il codice che controlla output.status continua a funzionare il giorno in cui viene aggiunto un nuovo stato, invece di ciclare all'infinito su quello. Quando ti serve distinguere i tre modi di fallire, output.flow.status è sempre lì.

Le stesse due parole funzionano su una busta: GET /api/v1/sign/envelopes/{id} risponde con la stessa identica forma, con output.sign al posto di output.flow. Un solo poller, per entrambi i percorsi.

Vedi, reinvia e prova i tuoi webhook

Nella console, Webhook elenca ogni notifica che abbiamo inviato al tuo sistema — l'evento, l'URL, i nostri tentativi, cosa ha risposto il tuo server — e il corpo esatto. Cosa puoi fare lì:

Invia di nuovo. Mette in coda una nuova consegna con lo stesso corpo memorizzato: gli stessi byte e lo stesso event.id, così un ricevitore che deduplica lo riconosce e uno che non lo fa riceve esattamente ciò che gli era stato inviato la prima volta. Segue la normale pianificazione e i normali tentativi; l'originale conserva la sua cronologia.
Invia di nuovo tutti gli abbandonati. Dopo che il tuo server è rimasto giù più a lungo dei nostri tentativi (44 ore), una pressione rimette in coda ogni evento abbandonato, dal più vecchio, ciascuno esattamente come farebbe Invia di nuovo; un evento già reinviato non viene mai messo in coda due volte, e ne partono al massimo 200 per pressione.
Invia un evento di esempio. Un evento inventato nella forma reale, firmato con il tuo segreto, inviato subito con lo stesso codice di uno vero (solo https, solo indirizzi pubblici, nessun redirect). Riporta event.simulated: true dentro il corpo firmato e non viene mai ritentato, così puoi scrivere il tuo handler prima di avere una busta reale.
Tutte queste azioni sono registrate nell'audit e limitate per organizzazione.

Tabella completa degli stati: Componi e firma, in una chiamata.