Ricevere eventi Stripe nell'endpoint del webhook
Inviare eventi all'account AWS
Adesso offriamo il supporto per la ricezione di eventi Stripe in Amazon EventBridge in versione beta privata. Per richiedere l’accesso anticipato, registrati su eventbridge.stripe.dev.
Perché utilizzare i webhook
Quando crei integrazioni Stripe, è consigliabile che le applicazioni ricevano gli eventi man mano che si verificano nei tuoi account Stripe, in modo che i sistemi di back-end possano eseguire le azioni in maniera adeguata.
Per abilitare gli eventi del webhook, devi registrare gli endpoint del webhook. Dopo averli registrati, Stripe può inviare i dati degli eventi in tempo reale all’endpoint del webhook della tua applicazione quando si verificano eventi nel tuo account Stripe. Stripe utilizza HTTPS per inviare eventi del webhook alla tua app come payload JSON che include un oggetto Event.
La ricezione di eventi webhook è particolarmente utile per gli eventi asincroni, come quando la banca del cliente conferma un pagamento, un cliente contesta un addebito, un pagamento ricorrente va a buon fine o vengono riscossi pagamenti in abbonamento.
Panoramica degli eventi
Stripe genera dati sugli eventi che possiamo inviarti per informarti dell’attività nel tuo account.
Quando si verifica un evento, Stripe genera un nuovo oggetto Event. Una singola richiesta API potrebbe comportare la creazione di più eventi. Ad esempio, se crei un nuovo abbonamento per un cliente, ricevi gli eventi customer.subscription.created
e payment_intent.succeeded
.
Registrando gli endpoint dei webhook nel tuo account Stripe, autorizzi Stripe a inviare automaticamente oggetti Event come parte delle richieste POST all’endpoint del webhook registrato ospitato dalla tua applicazione. Dopo che l’endpoint del tuo webhook ha ricevuto l’Event, la tua app può eseguire azioni di back-end (ad esempio, chiamare le API del tuo fornitore di servizi di spedizione per pianificare una spedizione dopo aver ricevuto un evento payment_intent.succeeded
).
Oggetto Event
L’oggetto Event che inviamo all’endpoint del webhook fornisce un’istantanea dell’oggetto modificato. Potrebbe includere una proprietà previous_attributes
che indica la modifica, se applicabile.
Consulta l’elenco di tutti i tipi di evento che inviamo al tuo webhook.
Esempio di payload dell’evento
Il seguente evento mostra un aggiornamento dell’abbonamento al termine di un periodo di prova.
{ "id": "evt_1MqqbKLt4dXK03v5qaIbiNCC", "object": "event", "api_version": "2024-04-10", "created": 1680064028,
Struttura dell’oggetto Event
Rivedi la struttura dell’oggetto dell’evento per comprendere meglio gli eventi e le informazioni che questi forniscono.
Tipo di evento
Ricevi eventi per tutti i tipi di evento che l’endpoint del webhook sta ascoltando nella tua configurazione. Usa l’attributo type
di evento ricevuto per determinare quale elaborazione deve eseguire la tua applicazione. L’attributo data.object
che corrisponde a ciascun type
di evento varia.
Modalità live e di test
Potresti ricevere richieste di consegna di eventi sia in modalità live che di test ai tuoi endpoint. Ciò può accadere se utilizzi un singolo endpoint sia per la modalità live che per la modalità di test o se sei una piattaforma Connect che effettua richieste in modalità di test per account live Standard connessi. Utilizza l’attributo livemode
per verificare se l’oggetto esiste in modalità live o test e determina la gestione corretta per l’evento.
Versione API
L’attributo api_version
indica la versione API dell’evento e detta la struttura del data.object incluso. L’endpoint riceve gli eventi utilizzando la versione API configurata, che può differire dalla versione API predefinita dell’account o dalla versione API di qualsiasi richiesta relativa all’evento. Questo attributo è determinato dall’endpoint di destinazione, che indica che lo stesso evento potrebbe essere consegnato a più endpoint utilizzando versioni API diverse. Se utilizzi le nostre librerie client Java, .NET o Go, assicurati di configurare la versione API dell’endpoint per utilizzare la stessa versione API associata al client. In caso contrario, potresti non riuscire a deserializzare gli oggetti evento.
Quando recuperi oggetti Event dalla API, non puoi controllare la versione API della struttura data.object
. Invece, puoi recuperare quell’oggetto dall’endpoint API appropriato e utilizzare l’intestazione Stripe-Version
per specificare una versione API.
Eventi della richiesta API
Quando un evento viene generato in seguito a una richiesta API, tale richiesta viene visualizzata come request.id
. Se utilizzi una idempotency_key
quando effettui la richiesta, viene inclusa come request.idempotency_key
. Seleziona l’hash request
se indaghi sulla causa di un evento.
Oggetto dati e attributi precedenti
Per gli eventi *.updated
, il payload dell’evento include data.previous_attributes
che consentono di ispezionare le modifiche apportate all’oggetto Stripe. L’evento previous_ attributes
nell’esempio customer.subscription.updated
sopra menzionato indica che l’abbonamento ha un valore precedente di status: trialing
, tra le altre modifiche. Il data.object
indica lo stato active
, il che significa che l’abbonamento ha superato un periodo di prova.
Consegne in sospeso
Utilizza pending_webhooks
per determinare quanti endpoint configurati per questo evento non hanno risposto correttamente alla consegna. Durante la consegna iniziale, questo valore è 1 o superiore perché l’endpoint non ha risposto correttamente. Se recuperi questo evento in seguito, pending_webhooks
diminuisce fino a un minimo di 0 quando ogni endpoint risponde correttamente. Questo è importante per gli eventi invoice.created
perché le consegne non riuscite possono ritardare la finalizzazione della fattura.
Eventi degli account connessi
Gli eventi degli account connessi consegnati a un endpoint Connect includono l’attributo account
. Utilizza questro attributo per tenere traccia dell’account connesso a cui appartiene l’oggetto per assicurarti che la tua piattaforma possa elaborare i dati dell’evento in modo appropriato.
Perché vengono generati gli oggetti Event
Questa tabella descrive diversi scenari che attivano la generazione di oggetti Event.
Origine | Attivatore |
---|---|
Dashboard | Quando chiami una API modificando le risorse Stripe nella Dashboard Stripe. |
API | Quando un’azione dell’utente nella tua app o nel tuo sito web comporta una chiamata API. |
API | Quando attivi manualmente un evento con la CLI di Stripe. |
API | Quando chiami una API direttamente con la CLI di Stripe. |
Per iniziare
Per iniziare a ricevere eventi webhook nella tua app, crea e registra un endpoint del webhook seguendo i passaggi riportati di seguito:
- Crea un gestore di endpoint del webhook per ricevere richieste POST dei dati degli eventi.
- Verifica localmente il gestore di endpoint del webhook utilizzando la CLI di Stripe.
- Registra il tuo endpoint in Stripe utilizzando la Dashboard o l’API.
- Proteggi l’endpoint del webhook.
Puoi registrare e creare un endpoint per gestire diversi tipi di eventi contemporaneamente o impostare singoli endpoint per eventi specifici.
Crea un gestore
Configura una funzione endpoint HTTP o HTTPS in grado di accettare richieste di webhook con un metodo POST. Se stai ancora sviluppando la tua funzione endpoint su dispositivi locali, questa può utilizzare il protocollo HTTP. Quando sarà accessibile pubblicamente, la funzione endpoint del webhook dovrà utilizzare il protocollo HTTPS.
Configura la funzione dell’endpoint in modo che:
- Gestisca le richieste POST con un payload JSON costituito da un oggetto Event.
- Restituisca rapidamente un codice di stato OK (
2xx
) prima che l’esecuzione di qualsiasi logica complessa possa causare un timeout. Ad esempio, devi restituire una risposta200
prima che la fattura di un cliente venga aggiornata come pagata nel sistema di contabilità.
Nota
In alternativa, puoi creare una funzione endpoint del webhook nel tuo linguaggio di programmazione utilizzando il nostro strumento interattivo per la creazione di endpoint del webhook.
Endpoint di esempio
Questo frammento di codice è una funzione webhook configurata per verificare che il tipo di evento sia stato ricevuto, per gestire l’evento e restituire una risposta 200.
Testa il gestore
Prima di passare alla modalità live con la funzione endpoint del webhook, ti consigliamo di verificare l’integrazione dell’applicazione. Puoi farlo configurando un listener locale per inviare eventi al tuo dispositivo locale e inviando eventi di test. Per eseguire il test, devi utilizzare la CLI.
Inoltrare gli eventi a un endpoint locale
Per inoltrare gli eventi all’endpoint locale, esegui il seguente comando con la CLI per impostare un listener locale. Il flag --forward-to
invia tutti gli eventi Stripe nella modalità di test all’endpoint del webhook locale.
stripe listen --forward-to localhost:4242/stripe_webhooks
Nota
Inoltre, puoi eseguire il comando listen di Stripe sulla shell di Stripe per visualizzare gli eventi tramite la shell di Stripe Terminal, anche se non potrai inoltrare gli eventi dalla shell all’endpoint locale.
Le configurazioni utili per aiutarti a eseguire i test con il tuo listener locale includono quanto segue:
- Per disabilitare la verifica del certificato HTTPS, usa il flag
--skip-verify
. - Per inoltrare solo eventi specifici, utilizza il flag opzionale
--events
e specifica un elenco di eventi separati da virgola.
stripe listen --events payment_intent.created,customer.created,payment_intent.succeeded,checkout.session.completed,payment_intent.payment_failed \ --forward-to localhost:4242/webhook
- Per inoltrare gli eventi al tuo endpoint del webhook locale dall’endpoint del webhook pubblico che hai già registrato su Stripe, utilizza il flag facoltativo
--load-from-webhooks-api
. Questo flag carica il tuo endpoint registrato, analizza il percorso e gli eventi registrati, poi aggiunge il percorso al tuo endpoint del webhook locale nel percorso--forward-to path
.
stripe listen --load-from-webhooks-api --forward-to localhost:5000
- Per controllare le firme dei webhook, utilizza
{{WEBHOOK_SIGNING_SECRET}}
dall’output iniziale del comando listen.
Ready! Your webhook signing secret is '{{WEBHOOK_SIGNING_SECRET}}' (^C to quit)
Attivare eventi di test
Per inviare eventi di test, attiva un tipo di evento a cui è abbonata la tua destinazione evento creando manualmente un oggetto tramite la Dashboard di Stripe. In alternativa, puoi utilizzare il seguente comando nella shell di Stripe o nella CLI di Stripe.
Questo esempio attiva un evento payment_intent.succeeded
:
stripe trigger payment_intent.succeeded Running fixture for: payment_intent Trigger succeeded! Check dashboard for event details.
Nota
Scopri come attivare gli eventi con Stripe for Visual Studio Code.
Registra il tuo endpoint in Stripe
Dopo aver testato la funzione dell’endpoint del webhook, registra l’URL accessibile dell’endpoint del webhook utilizzando la sezione Webhook nella Dashboard per gli sviluppatori o l’API in modo che Stripe sappia dove consegnare gli eventi. Stripe ti consente di registrare fino a 16 endpoint del webhook. Gli endpoint del webhook registrati devono essere URL HTTPS accessibili pubblicamente.
Formato dell’URL del webhook
Il formato dell’URL per registrare un endpoint del webhook è:
https://<your-website>/<your-webhook-endpoint>
Ad esempio, se il tuo dominio è https://mycompanysite.com
e il percorso verso l’endpoint del webhook è @app.route('/stripe_webhooks', methods=['POST'])
, specifica https://mycompanysite.com/stripe_webhooks
come URL dell’endpoint.
Aggiungere un endpoint del webhook
Nota
Se hai abilitato Workbench nel tuo account, devi utilizzare Workbench per registrare il tuo endpoint webhook.
Stripe supporta due tipi di endpoint, Account e Connect. Crea un endpoint di tipo Account, a meno che tu non abbia creato un’applicazione Connect. Attieniti alla procedura indicata di seguito per registrare un endpoint del webhook nella Dashboard per sviluppatori. Puoi registrare fino a 16 endpoint del webhook su ogni account Stripe.
- Vai alla pagina Webhook.
- Fai clic su Aggiungi endpoint.
- Aggiungi l’URL HTTPS dell’endpoint del webhook in URL endpoint.
- Se hai un account Stripe Connect, inserisci una descrizione, poi fai clic su Ascolta gli eventi sugli account connessi.
- Seleziona i tipi di evento che ricevi al momento nel tuo endpoint del webhook locale in Seleziona eventi.
- Fai clic su Aggiungi endpoint.
Registra un endpoint del webhook con l’API di Stripe
Puoi anche creare endpoint dei webhook automaticamente.
Per ricevere eventi dagli account connessi, utilizza il parametro connect.
Il seguente esempio mostra come creare un endpoint che ti informa dell’esito positivo o negativo degli addebiti.
Proteggi il tuo endpoint
Ti consigliamo vivamente di proteggere l’integrazione assicurandoti che il gestore verifichi che tutte le richieste di webhook vengano generate da Stripe. Puoi scegliere di verificare le firme dei webhook utilizzando le nostre librerie ufficiali o verificarle manualmente.
Eseguire il debug delle integrazioni dei webhook
Durante la consegna di eventi all’endpoint del webhook, possono verificarsi diversi tipi di problemi:
- Stripe potrebbe non essere in grado di consegnare un evento all’endpoint del webhook.
- L’endpoint del webhook potrebbe avere un problema al certificato SSL.
- La connettività di rete è intermittente.
- L’endpoint del webhook non riceve gli eventi che ti aspetti di ricevere.
Visualizzare le consegne dell’evento
Nota
Se hai abilitato Workbench nel tuo account, devi utilizzare Workbench per gestire le consegne degli eventi.
Per visualizzare le consegne degli eventi per un endpoint specifico, seleziona l’endpoint del webhook nella scheda Webhook.
Per visualizzare tutti gli eventi attivati nel tuo account, consulta la scheda Eventi.
Correggere i codici di stato HTTP
Quando un evento visualizza un codice di stato 200
, indica l’avvenuta consegna all’endpoint del webhook. Potresti anche ricevere un codice di stato diverso da 200
. Consulta la tabella riportata di seguito per un elenco dei codici di stato HTTP comuni e delle soluzioni consigliate.
Stato del webhook in sospeso | Descrizione | Correzione |
---|---|---|
ERR (Impossibile connettersi) | Non è stato possibile stabilire una connessione con il server di destinazione. | Assicurati che il tuo dominio host sia accessibile pubblicamente su internet. |
ERR (302 ) (o altro stato 3xx ) | Il server di destinazione ha tentato di reindirizzare la richiesta a un’altra posizione. Le risposte di reindirizzamento alle richieste di webhook sono considerate errori. | Imposta la destinazione dell’endpoint del webhook sull’URL risolto dal reindirizzamento. |
ERR (400 ) (o altro stato 4xx ) | Il server di destinazione non elabora la richiesta o non è in grado di farlo. Ciò può verificarsi quando il server rileva un errore (400 ), quando l’URL di destinazione ha limitazioni di accesso (401 , 403 ) o quando l’URL di destinazione non esiste (404 ). |
|
ERR (500 ) (o altro stato 5xx ) | Il server di destinazione ha rilevato un errore durante l’elaborazione della richiesta. | Esamina i registri della tua applicazione per capire perché restituisce un errore 500 . |
ERR (Errore TLS) | Non è stato possibile stabilire una connessione sicura con il server di destinazione. Questi errori, in genere, sono causati da un problema con il certificato SSL/TLS o un certificato intermedio nella catena di certificati del server di destinazione. | Esegui un test del server SSL per individuare i problemi che potrebbero aver causato l’errore. |
ERR (Tempo scaduto) | Il server di destinazione ha impiegato troppo tempo per rispondere alla richiesta di webhook. | Assicurati di rinviare la logica complessa e restituire immediatamente una risposta positiva nel codice di gestione del webhook. |
Comportamenti di consegna degli eventi
Questa sezione ti aiuta a comprendere i vari comportamenti da aspettarsi per quanto riguarda il modo in cui Stripe invia gli eventi all’endpoint del webhook.
Ripetizione del comportamento
In modalità live, Stripe cerca di consegnare un determinato evento all’endpoint del webhook per un massimo di 3 giorni con un ritardo di attesa esponenziale. Nella sezione Eventi della Dashboard, puoi visualizzare quando verrà ripetuto il tentativo successivo.
In modalità di test, Stripe esegue tre tentativi nell’arco di alcune ore. Dopo questo periodo di tempo, puoi eseguire questi tentativi per i webhook manualmente utilizzando la sezione Eventi della Dashboard. Inoltre, puoi inviare query per gli eventi persi al fine di riconciliare i dati per un periodo di tempo qualsiasi.
I tentativi automatici proseguono, anche se riprovi la trasmissione manuale di eventi di webhook singoli a un determinato endpoint e il tentativo ha esito positivo.
Se l’endpoint viene disabilitato o eliminato durante un tentativo di Stripe, eventuali futuri tentativi di quell’evento vengono impediti. Tuttavia, se disabiliti e poi abiliti nuovamente un endpoint del webhook prima che Stripe possa riprovare, puoi comunque visualizzare i tentativi futuri.
Disabilitazione del comportamento
In modalità di test e live, Stripe cercherà di segnalarti via email un endpoit non configurato correttamente in caso di mancata risposta con codice di stato HTTP 2xx
per più giorni di fila. Nell’email viene indicato anche quando l’endpoint verrà disabilitato automaticamente.
Controllo delle versioni dell’API
La versione dell’API nelle impostazioni dell’account quando si verifica l’evento determina la versione dell’API e la struttura di un oggetto Event
inviato in un webhook. Ad esempio, se l’account è impostato su una versione dell’API precedente, ad esempio 2015-02-16, e modifichi la versione dell’API per una richiesta specifica con il controllo delle versioni, l’oggetto Event
generato e inviato all’endpoint è ancora basato sulla versione dell’API 2015-02-16.
Non è possibile modificare gli oggetti Event
dopo la creazione. Ad esempio, se un addebito viene aggiornato, quello originale rimane invariato. Di conseguenza gli aggiornamenti successivi della versione dell’API dell’account non modificano in modo retroattivo gli oggetti Event
esistenti. Anche il recupero di oggetti Event
precedenti chiamando /v1/events
con una versione più recente dell’API non influisce sulla struttura degli eventi ricevuti.
Puoi impostare gli endpoint dei webhook sulla versione predefinita dell’API o su quella più recente dell’API. L’oggetto Event
inviato all’URL del webhook è strutturato in funzione della versione specifica dell’endpoint. Puoi anche creare endpoint automaticamente con un parametro api_version.
Ordine degli eventi
Stripe non garantisce la consegna degli eventi nell’ordine in cui sono stati generati. Ad esempio, la creazione di un abbonamento potrebbe generare i seguenti eventi:
customer.subscription.created
invoice.created
invoice.paid
charge.created
(se esiste un addebito)
L’endpoint non deve aspettarsi la consegna degli eventi in quest’ordine e quindi deve gestire le consegne in modo appropriato. Puoi anche utilizzare l’API per recuperare eventuali oggetti mancanti. Ad esempio, puoi recuperare gli oggetti Invoice, Charge e Subscription utilizzando le informazioni contenute nell’evento invoice.paid
, se l’hai ricevuto per primo.
Pratiche ottimali di utilizzo dei webhook
Rivedi le pratiche ottimali per proteggere i webhook e garantirne il corretto funzionamento nella tua integrazione.
Gestire gli eventi duplicati
A volte gli endpoint dei webhook potrebbero ricevere lo stesso evento più di una volta. Per proteggerti dalla ricezione di eventi duplicati, rendi idempotente l’elaborazione degli eventi. A tal fine, puoi ad esempio registrare gli eventi elaborati e non elaborare gli eventi già registrati.
Ascoltare solo i tipi di evento richiesti dall’integrazione
Configura gli endpoint dei webhook per ricevere solo i tipi di eventi richiesti dalla tua integrazione. L’ascolto di altri eventi (o di tutti gli eventi) appesantisce inutilmente il server e pertanto è sconsigliato.
Puoi modificare gli eventi che un endpoint del webhook riceve attraverso la Dashboard o l’API.
Gestire gli eventi in modo asincrono
Configura il gestore per elaborare gli eventi in arrivo con una coda asincrona. Se scegli di elaborare gli eventi in modo sincrono, potrebbero verificarsi problemi di scalabilità. Un forte aumento delle consegne di webhook (ad esempio, all’inizio del mese, quando tutti gli abbonamenti vengono rinnovati) può sovraccaricare gli host degli endpoint.
Le code asincrone ti consentono di elaborare gli eventi simultanei a una velocità che il tuo sistema è in grado di supportare.
Esentare il percorso dei webhook dalla protezione CSRF
Se utilizzi Rails, Django o un altro framework web, il tuo sito potrebbe verificare automaticamente che ogni richiesta POST contenga un token CSRF. Questa importante misura di sicurezza consente di proteggere te e i tuoi utenti da eventuali tentativi di falsificazione della richiesta tra siti. Tuttavia, questa misura di sicurezza potrebbe anche impedire al sito di elaborare gli eventi legittimi. In tal caso, potrebbe essere necessario escludere il percorso dei webhook dalla protezione CSRF.
Ricevere eventi con un server HTTPS
Se utilizzi un URL HTTPS per l’endpoint del webhook, prima di inviare i dati del webhook Stripe verifica che la connessione al tuo server sia sicura. Per eseguire questa procedura, il tuo server deve essere configurato correttamente per supportare il protocollo HTTPS e deve disporre di un certificato valido. La modalità live richiede URL HTTPS. I webhook di Stripe al momento non supportano TLS v1.3.
Revocare periodicamente le chiavi private della firma digitale
La chiave privata utilizzata per verificare gli eventi provenienti da Stripe è modificabile nella sezione Webhook della Dashboard. Per ogni endpoint, fai clic su Revoca chiave privata. Puoi scegliere di far scadere immediatamente la chiave privata corrente o ritardarne la scadenza per 24 ore per darti il tempo di aggiornare il codice di verifica sul server. In quel periodo di tempo sono attive più chiavi private per l’endpoint. Stripe genera una firma per chiave privata fino alla scadenza. Per tenerle al sicuro, ti consigliamo di revocare le chiavi private periodicamente o nei casi in cui sospetti che una chiave privata sia stata compromessa.
Verificare che gli eventi provengano da Stripe
Stripe invia eventi webhook da un elenco predefinito di indirizzi IP. Considera attendibili solo gli eventi provenienti da tali indirizzi IP.
Inoltre, verifica le firme dei webhook per confermare che gli eventi ricevuti siano inviati da Stripe. Stripe firma gli eventi webhook che invia agli endpoint aggiungendo una firma nell’intestazione Stripe-Signature
di ogni evento. In questo modo puoi verificare che gli eventi siano stati inviati da Stripe e non da una terza parte. Puoi verificare le firme utilizzando le nostre librerie ufficiali oppure verificarle manualmente con una tua soluzione.
La sezione seguente descrive come verificare le firme dei webhook:
- Recupera la chiave privata del tuo endpoint.
- Verifica la firma.
Recuperare la chiave privata dell’endpoint
Utilizza la sezione Webhook della Dashboard. Seleziona un endpoint per il quale vuoi ricevere la chiave privata. La chiave privata viene visualizzata in alto a destra della pagina.
Stripe genere una chiave privata unica per ogni endpoint. Se utilizzi lo stesso endpoint per le chiavi API di test e live, la chiave privata è diversa per ogni modalità. Inoltre, se utilizzi più endpoint, per verificare le firme devi richiedere una chiave privata per ognuno di essi. In questo modo, Stripe inizia a firmare ogni webhook che invia all’endpoint.
Impedire gli attacchi di tipo replay
Un attacco di tipo replay si verifica quando un utente malintenzionato intercetta un paylod valido e la sua firma e poi li ritrasmette. Per mitigare questi attacchi, Stripe include un timestamp nell’intestazione Stripe-Signature
. Dato che il timestamp fa parte del payload firmato, viene anch’esso verificato dalla firma e quindi un utente malintenzionato non può modificare il timestamp senza invalidare la firma. Se la firma è valida ma il timestamp è troppo vecchio, puoi fare in modo che la tua applicazione rifiuti il payload.
Le nostre librerie hanno una tolleranza predefinita di 5 minuti tra il timestamp e l’ora corrente. Per modificarla, devi specificare un ulteriore parametro quando verifichi le firme. Utilizza il Network Time Protocol (NTP) per garantire che l’orologio del server sia preciso e sincronizzato con l’ora dei server di Stripe.
Stripe genera il timestamp e la firma di ogni evento inviato all’endpoint. Se Stripe tenta di inviare di nuovo un evento, ad esempio perché in precedenza l’endpoint aveva risposto con un codice di stato diverso da 2xx
, per il nuovo tentativo di consegna vengono generati una nuova firma e un nuovo timestamp.
Restituire rapidamente una risposta 2xx
L’endpoint deve restituire rapidamente un codice di stato OK (2xx
) prima che l’esecuzione di qualsiasi logica complessa possa causare un timeout. Ad esempio, devi restituire una risposta 200
prima che la fattura di un cliente venga aggiornata come pagata nel sistema contabile.