Questo passaggio consente di inviare richieste HTTP e di salvare le relative risposte come variabili.
Questo passaggio è disponibile solo per i piani Advanced e superiori.

Configurazione
Ci sono due configurazioni chiave nella fase di richiesta HTTP:
Metodo di richiesta HTTP
Il metodo specifico richiesto per la richiesta. Selezionare il metodo appropriato dall'elenco a discesa.

URL
Nel campo URL, immettere l'endpoint URL dell'API esterna per recuperare i dati. Per includere le variabili, utilizzare il prefisso "$" per supportare l'interpolazione di testo statico e variabili.

Ora puoi utilizzare indirizzi IP e numeri di porta nella fase di richiesta HTTP, ottenendo così accesso diretto ai server e flessibilità nell'accesso ai servizi su porte non standard.
Nota che il dominio respond.io è nella blacklist. L'invio di una chiamata API a questo dominio non è consentito, in quanto potrebbe causare cicli infiniti.
Corpo
Per garantire la corretta decodifica da parte del destinatario della richiesta, espandere la sezione Corpo e includere un corpo insieme all'intestazione Content-Type.

Intestazioni
Nella sezione Intestazione è possibile aggiungere intestazioni alla richiesta HTTP in coppie. La chiave rappresenta il nome dell'intestazione, mentre il valore rappresenta il valore dell'intestazione. È possibile utilizzare le variabili come intestazioni aggiungendo il prefisso "$". Tuttavia, tieni presente che sono consentite solo fino a 10 intestazioni.

Mappatura delle risposte
Per le risposte API JSON, puoi salvare valori specifici della risposta come variabili. Nella sezione Response Mapping, inserisci il percorso/riferimento JSON del valore a sinistra e assegna un nome alla variabile a destra.
Il campo JSON Key deve contenere il percorso/riferimento JSON al valore che vuoi salvare, iniziando dalla radice della risposta con `$`. Ad esempio, per `{"phone":"123123"}`, inserisci `$.phone`, non `phone`.

Esempi:
Per salvare valori da diversi formati di risposta, compila il campo JSON Key usando il percorso JSON ai dati che vuoi salvare.
{
"nome": "Jason",
"codici_postali": "12345",
"telefono": "123123"
}Per salvare il numero di telefono dalla risposta sopra, inserisci $.phone nel campo JSON Key.
{
"custom_fields": {
"firstName": "John",
"lastName": "Doe",
"locale": "en_GB",
"timezone": "5",
"gender": "male",
"phone": "123123",
"email": "zy@respond.io",
"customerid": "1"
},
"created_at": 1575618542
}Per salvare il numero di telefono dalla risposta sopra, inserisci $.custom_fields.phone nel campo JSON Key.
{
"dati": {
"id":"1776025372480910",
"contatti" : [
{
"nome":"John",
"cognome":"Doe",
"locale": "en_GB"
},
{
"nome":"Jane",
"cognome":"Doe",
"locale": "en_GB"
}
]
}
}Per salvare il nome 'Jane' dalla risposta sopra, inserisci $.data.contacts[1].firstName nel campo JSON Key.
Salva lo stato della risposta come variabile
Per salvare lo stato della risposta dalla richiesta HTTP come variabile, attivare l'opzione Salva stato risposta come variabile . Quindi, assegna un nome alla variabile nel campo fornito.

Come funziona
Una volta attivato, questo passaggio invierà una richiesta HTTP all'URL specificato, utilizzando il corpo e l'intestazione definiti.
È possibile guidare il flusso di lavoro in base allo stato della risposta. Ad esempio, puoi creare un ramo per il codice di stato "uguale a 200". Se viene ricevuto un altro codice di stato di risposta, un Jump Step potrebbe restituire i Contatti al HTTP Request Step. In alternativa, se le condizioni della filiale non vengono soddisfatte, il contatto potrebbe essere indirizzato alla filiale in errore. Se non sono impostati passaggi nel ramo Errore, il flusso di lavoro verrà concluso.
Se la richiesta HTTP supera i 10 secondi, si verificherà un timeout, che impedirà alla richiesta di andare a buon fine.
Potenziale fallimento
Per evitare potenziali errori nell'esecuzione delle richieste HTTP, assicurarsi che siano soddisfatte le seguenti condizioni:
Utilizzare il metodo HTTP e l'intestazione Content-Type corretti.
Assicurati di includere il protocollo richiesto
http://ohttps://nel tuo URL in base a ciò che supporta il tuo sistema per evitare errori nella richiesta.Assicurarsi che il Content-Type sia valido.
Escludere il numero di porta dall'URL.
Evitare di utilizzare un certificato autofirmato nell'URL.
Verificare che l'autorizzazione sia valida.
Assicuratevi che i nostri indirizzi IP (52.74.35.155, 18.138.31.163, 54.169.155.20) non siano bloccati.
Se una qualsiasi delle condizioni di cui sopra non viene soddisfatta, il Contatto salterà questo passaggio e procederà con il viaggio rimanente.
Quando si verificano gli output delle richieste HTTP con variabili dinamiche, tenere presente che le variabili senza valore verranno restituite come null e undefined.
Migliori pratiche
Ecco alcune best practice che puoi seguire per ottimizzare il tuo flusso di lavoro in questa fase:
Quando la richiesta HTTP ha esito positivo
Salva lo stato della risposta come variabile:
Assicurati che il primo passaggio sia salvare lo stato della risposta come variabile per le azioni successive.
Passo di diramazione:
Aggiungere un Branch Step per valutare lo stato della richiesta HTTP.
Se lo stato è
200, la richiesta ha esito positivo.In caso contrario, configurare un avviso per notificare al gestore la richiesta non riuscita.
Google Sheetper il monitoraggio:
Registra lo stato della risposta in un foglio di calcolo di Google per avere una chiara visibilità sul successo o sul fallimento delle richieste.
Commento:
Aggiungi un commento nel tuo flusso di lavoro per documentare lo stato della risposta. Ciò ti aiuterà a monitorare e rivedere gli errori in modo più efficiente.
Quando la richiesta HTTP fallisce
Salva lo stato della risposta come variabile:
Analogamente alla richiesta riuscita, salva lo stato della risposta come variabile per la gestione degli errori.
Usa Attendi o Salta il passo per i nuovi tentativi:
Implementare il Wait Step per mettere in pausa prima di riprovare una richiesta non riuscita.
In alternativa, utilizzare il passaggio Jump per tornare al passaggio di richiesta HTTP e tentare nuovamente la richiesta.
Commento:
Documentare l'errore creando un commento per registrare l'errore della richiesta HTTP
Includi i dettagli di contatto e tagga la persona responsabile.
Foglio Google per il monitoraggio:
Utilizza il passaggio di Google Sheet per registrare le informazioni di contatto e i dettagli degli errori a scopo di monitoraggio e revisione.
Assegnazione attività:
Assegnare l'attività a un utente specifico per avviare un altro processo all'interno del flusso di lavoro e riprovare.
Casi d'uso suggeriti
Ecco alcuni modi in cui puoi utilizzare il passaggio di richiesta HTTP:
Instrada i contatti VIP: utilizza lo step HTTP Request per recuperare i dettagli dei contatti da un data warehouse come un CRM. Ciò consente di identificare i contatti VIP, consentendo un'esperienza cliente personalizzata e distinguendoli dai contatti non VIP.
FAQ e risoluzione dei problemi
Posso chiamare un endpoint API che richiede l'autenticazione OAuth 2.0?
No. HTTP Request non supporta i flussi di autenticazione OAuth 2.0, come il consenso dell'utente, lo scambio del codice di autorizzazione, l'aggiornamento del token di accesso o la generazione dinamica di token.
Puoi usare HTTP Request con endpoint che accettano metodi di autenticazione semplici, come API key o token statici aggiunti all'URL, ai parametri di query o agli header.
Ad esempio, se stai chiamando un endpoint API di Google e la richiesta fallisce, verifica se quell'endpoint richiede l'autenticazione OAuth 2.0. Se lo richiede, non è supportato. Se invece l'endpoint supporta API key o token statici, puoi usare quel metodo di autenticazione nella configurazione di HTTP Request.