Make HTTP requests with Logic

Use the Make HTTP request block to connect Logic with your external tech stack.

HTTP requests are powerful tools for accessing external resources and making your site more interactive. You can use Webflow Logic’s Make HTTP request block to request information from or send information to third-party applications. Then, you can use the response data in subsequent steps in your flow — seamlessly connecting Logic with your external apps. 

What is an HTTP request? 

HTTP, or Hypertext Transfer Protocol, is a protocol used to communicate data over the internet. The internet consists of resources (e.g., HTML files, stylesheets, scripts, images, etc.) hosted on many different servers. HTTP requests allow us to access these resources.

To access content on the internet, your browser (or “the client”) must send requests to these servers for the resources it wants. Then, when the servers respond with the requested resources, the browser will display these resources to you. HTTP requests allow you to view this page right now! 

When you type “webflow.com” (or any other URL) into your browser’s address bar, your browser sends a GET request to the server to retrieve the webpage so it can display it in the browser. GET requests are one type of HTTP method a client can use to request a resource. We’ll learn more about the other common request methods (POST, PUT, PATCH, and DELETE) later in this lesson. 

Making HTTP requests with Logic

In the context of Logic, you can automate HTTP requests to APIs. An API, or application programming interface, is essentially an intermediary that allows 2 different applications to talk to each other — in this case, your Logic flow and your external tech stack (i.e., the combination of tools and services used to power your site). For example, you could request records from Airtable to use in your flow, or send data from your Webflow site to Airtable. You can use APIs to perform CRUD operations and power your apps. 

CRUD operations refer to the 4 basic operations software applications should be able to perform — Create, Read, Update, and Delete. Users must be able to create data, read data (i.e., have access to the data in the application user interface), update or edit the data, and delete the data. You can think of the Webflow CMS as a CRUD application where you can create, view (read), edit (update), and delete CMS items. 

The most common HTTP request methods correspond to CRUD operations:

To provide a real-world analogy, an API is like a bank, and CRUD operations are like the actions you can take at a bank. When you visit a bank, you can access (read) records of your available funds and transactions, deposit (create) money to your account, update your account information, and withdraw (delete) money from your account. Before you can take any of these actions at the bank, you have to authenticate yourself with your identification and tell the bank what you’d like to do — and the same principles apply to working with APIs. 

How to get started

To get started with making HTTP requests in Logic: 

1. Open Logic panel > Flows > Flow editor
2. Drag a Make HTTP request block to the canvas

The anatomy of an HTTP request

An HTTP request must have:

• A request method
• A request URL and endpoint path

Optionally, an HTTP request can also have:

• Authentication
• A request body
• Request headers
• Query strings

Authentication

Similar to presenting your identification at a bank, many APIs require you to identify (i.e., authenticate) yourself when requesting resources. There are 3 options for authentication: 

• None (for APIs that don’t require authentication)
• API token
• Username & password

How to add an API token credential

Similar to a password, an API token (sometimes called an “API key” or “access token”) identifies the site or application making an HTTP request to an API. All API tokens you use with Logic are stored securely.

In request headers

To add an API token credential to your request headers: 

1. Copy your API token for the API where you’re sending your request
2. Open Logic panel > Flows tab > Flow editor in Webflow
3. Select the Make HTTP request block on the canvas to open Block settings
4. Choose API token from the Authentication dropdown
5. Choose Header from the Add to dropdown
6. Enter a value for your header (e.g., Authorization, X-API-Key, etc.) in the Header field 
7. Click Select a credential under Credential
8. Click Add new credential 
9. Give your API token a name (e.g., Airtable API token) in the Name field and add a description in the Description field if you’d like 
10. Choose API token from the Type dropdown
11. Paste your API token into the Token field
12. Click Create

Once you’ve added your API token, you can select it from the Credential dropdown for use in future HTTP requests.

In query parameters

To add an API token credential to your query parameters: 

1. Copy your API token for the API where you’re sending your request
2. Open Logic panel > Flows tab > Flow editor in Webflow
3. Select the Make HTTP request block on the canvas to open Block settings
4. Choose API token from the Authentication dropdown
5. Choose Query params from the Add to dropdown
6. Enter the key for your query parameter (e.g., “key” in key=value, or “api_key” in api_key=value) in the Query parameter field
7. Click Select a credential under Credential
8. Click Add new credential 
9. Give your API token a name (e.g., TMDB API key) in the Name field and add a description in the Description field if you’d like
10. Paste your API token into the Token field — this will be the value in your key/value pair
11. Click Create

Once you’ve added your API token, you can select it from the Credential dropdown for use in future HTTP requests.

How to add a username and password credential

Some APIs may require authentication with a username and password instead of an API token. All username and passwords you use with Logic are stored securely. 

To add a username and password credential:  

1. Open Logic panel > Flows tab > Flow editor in Webflow
2. Select the Make HTTP request block on the canvas to open its Block settings
3. Choose Username & password from the Authentication dropdown
4. Click Select a credential under Credential
5. Click Add new credential
6. Give your credentials a name (e.g., Mailchimp credentials) in the Name field and add a description in the Description field if you’d like
7. Choose Username & password in the Type dropdown
8. Enter your username and password in the Username and Password fields (the username and password are those from the external service) 
9. Click Create

Once you’ve added your username and password, you can select them from the Credential dropdown for use in future HTTP requests.

Request URL and endpoint path 

Every HTTP request must contain a request URL and endpoint path to indicate the server where you’re directing your request. 

For example, to create a new contact in Mailchimp using the Mailchimp API, you’d make a POST request to https://{region}.api.mailchimp.com/3.0/lists/{listID}/members. In this case, the request URL is https://{region}.api.mailchimp.com/3.0 and the endpoint path is /lists/{listID}/members. 

You can enter the request URL and endpoint path in the URL field of the Make HTTP request block settings. You can also click the purple “dot” icon in the URL field to add dynamic data (e.g., output data from previous blocks) to your request URL. 

Query strings

Query strings are an optional part of a URL that allows you to pass information to and from a server by appending that information to the end of the URL. Query strings typically follow a question mark (?) in the URL and can include one or more parameters as key/value pairs. An equals sign (=) separates each key and value (e.g., key=value) and an ampersand (&) separates multiple parameters (e.g., key1=value1&key2=value2). These can be used for authentication (e.g., adding an API token to the query parameters) or to send dynamic data (e.g., data generated through a form submission). 

Let’s say you want to use The Movie Database API to search for details about the movie Hot Rod. You’d send a GET request to https://api.themoviedb.org/3/search/movie?api_key={api_key}&query=Hot+Rod. In this example, api_key and query are keys, {api_key} is a placeholder value for an actual API token, and Hot+Rod is another value. These keys and values make up 2 parameters, which together make up the query string: ?api_key={api_key}&query=Hot+Rod. 

You can add dynamic data (e.g., output data from previous blocks) to your query parameters by clicking the purple “dot” icon in the URL field of the Make HTTP request block settings.

Request methods

HTTP request methods define the request’s action. The following request methods are available in the Make HTTP request block: 

• GET
• POST
• PUT
• PATCH
• DELETE

GET

You can use the GET request method to retrieve or read a resource. A successful GET request returns a response body that contains the information you requested. 

For example, you can use a GET request to retrieve information about your lists/audiences in Mailchimp, or a list of all the tables in your Airtable base. 

POST

You can use the POST request method to create a new resource in an external service or database. A POST request requires a request body in which you define the data for the resource you’d like to create. 

Let’s say you want to capture newsletter subscribers on your Webflow site and send them to a Mailchimp list. You can create a flow with a form submission trigger and a Make HTTP request block to send a POST request to Mailchimp. The request body in this example would be the form submission data you want to add to Mailchimp. 

PUT

You can use the PUT request method to modify or update a resource. If there’s no existing resource that matches the request to update, the request will create a new resource. 

For example, if you want to update an existing record in Airtable, you could send a PUT request to Airtable and pass in the full record from Airtable (i.e., the complete schema including all cell values and the existing record ID) along with the information you’d like to update in the request body. If the record doesn’t already exist in Airtable, your request would create a new record. If the record already exists in Airtable and you leave any of the existing cell values empty in your request body, the request would overwrite the existing record — meaning any previously filled cell values would be empty after the request is complete. 

Many third-party services require you to include an existing record ID or unique identifier in your PUT request to identify the record to update, rather than performing logic on their end to determine if a record already exists.

PATCH

The PATCH request method is similar to the PUT request method, but PATCH lets you modify or update part of a resource, rather than the whole resource. You only need to include the data you want to update in the request body.

For example, if you want to update the description field of an existing record in Airtable and leave the rest of the record the same, you could send a PATCH request and pass in only the record ID and the description you’d like to give the record. The PATCH request will only update the record’s description field, and will leave all of the other fields alone. 

DELETE 

You can use the DELETE request to delete a resource. 

For example, you could make a DELETE request to Mailchimp to delete an audience, or to Hubspot to delete a lead you no longer want to track.

Request headers

Request headers provide context about an HTTP request so the server can respond appropriately. For instance, you can use request headers in GET requests to tell the server to send its response in a particular format, or in POST requests to tell the server what type of data you’re sending. 

To add a request header to the Make HTTP request block: 

1. Open Make HTTP request block settings > General > Headers 
2. Click the “plus” icon 
3. Enter a name and value for your header

You can delete a request header by clicking the “trash” icon.

Request body

The request body consists of the data you’d like to send to the server in your request. In a POST request, for example, this would be the resource you want to create. The request body is optional for some requests — for example, when retrieving a resource using a GET request, you don’t need to specify anything in the body of the request. The Request body field appears in Make HTTP Request block settings > General when you select a method that uses a request body (i.e., POST, PUT, or PATCH). 

You’ll use JSON (JavaScript Object Notation) to structure your request body. JSON is a text-based data format that consists of key/value pairs written in double quotes and separated by a colon, like so: 

"Name": "Rod Kimble"

JSON objects, which make up the request body, can contain multiple key/value pairs, separated by commas. For example: 

{
  "Name": "Rod Kimble",
  "Occupation": "Stuntman"
}

You can use dynamic data from your flow in your request body by clicking the purple “dot” icon in the Body (JSON) field. Supported data types include: 

• Plain
• Email
• Phone 
• Number
• Text Area
• Checkbox
• Timestamp

How to manage authentication credentials

Credentials (e.g., API tokens, usernames and passwords, etc.) are stored securely in Webflow — always encrypted in transit and always encrypted at rest. Once a credential is created, no one, including the original creator of that credential, can see the actual value of the credential in the Webflow UI. You’ll only be able to see the user-defined names for created credentials. 

How to add new credentials

You can add a new credential by opening Block settings > Authentication > Select a credential and clicking Add new credential. The process for adding a credential differs depending on the credential type (i.e., API token or username & password). 

How to update or replace credentials

To update or replace a credential: 

1. Open Logic panel > Flows tab > Flow editor 
2. Select the Make HTTP request block on the canvas to open Block settings
3. Click Select a credential under Credential
4. Click Manage credentials
5. Choose the credential you’d like to update
6. Enter the new value for your credential (i.e., your updated API key or updated username & password) 
7. Click Save

How to unlink and delete credentials

To delete a credential, you’ll first need to unlink the credential from any Make HTTP request blocks where the credential is in use. 

To unlink a credential: 

1. Open Logic panel > Flows tab > Flow editor 
2. Select the Make HTTP request block on the canvas to open Block settings
3. Open the Credential dropdown 
4. Click Unlink credential

To delete a credential: 

1. Open Logic panel > Flows tab > Flow editor 
2. Select the Make HTTP request block on the canvas to open Block settings
3. Click Select a credential under Credential
4. Click Manage credentials
5. Choose the credential you’d like to delete
6. Click Delete credential
7. Click Delete credential in the Delete credential modal window

The anatomy of an HTTP response

Status code

HTTP response status codes are issued by a server in response to a client’s HTTP request. These status codes indicate whether the request has been successfully completed. HTTP response status codes are separated into 5 categories: 

• Informational responses
• Successful responses
• Redirection responses
• Client error responses
• Server error responses

Informational responses

Informational status codes indicate that the request was received and understood by the server, and tell the client to wait for the server’s final response. Codes beginning with “1” indicate an informational response. 

Check out the MDN documentation on informational responses.

Successful responses

Success status codes indicate a successful HTTP request — the action requested by the client was received, understood, and accepted by the server. Codes beginning with “2” indicate a successful response.

200 OK is the standard response for successful HTTP requests, but the response may differ depending on the request method. 201 Created, for example, is the most common response to successful POST requests. 

Check out the MDN documentation on successful responses.

Redirection responses

Redirection status codes indicate that the client must take additional steps to complete the HTTP request. This may happen if the request has more than one possible response, or if the URL of the requested resource has been changed permanently. Codes beginning with “3” indicate a redirection response. 

Check out the MDN documentation on redirection responses.

Client error responses

Client error status codes indicate that the server cannot or will not process the request due to an issue caused by the client. This means there’s an issue on the requestor’s (i.e., your) end. Client error status codes could be sent in response to requests sent with malformed syntax, without the required authentication, to a resource that doesn’t exist, etc. Codes beginning with “4” indicate a client error response. 

Check out the MDN documentation on client error responses.

Server error responses

Server error responses indicate that the server failed to complete a request or is incapable of completing a request. This means there’s an issue on the third-party service’s end. Codes beginning with “5” indicate a server error response. 

Check out the MDN documentation on server error responses.

Response headers

Response headers are HTTP headers that contain additional context for the response, such as information about the responding server, data type, host address, etc. 

Response body

When an HTTP request is successful, the response body contains either:

• the resource requested by the client, or 
• some information about the status of the action requested by the client

When an HTTP request is unsuccessful, the response body might provide:

• further information about the reasons for the error, or 
• some action that the client needs to take to complete their request

Not all responses will contain a response body. 

How to test Make HTTP request blocks

You can test Make HTTP request blocks separately from the rest of your flow for easier troubleshooting. 

To test a Make HTTP request block: 

1. Open Logic panel > Flows tab > Flow editor 
2. Right-click on the Make HTTP request block on the canvas and select Test this action, or select the Make HTTP request block on the canvas and click Run test to complete setup in Block settings
3. Enter sample data in the modal menu window
4. Click Run test

Learn more about testing flows.

Additional resources for testing HTTP requests

You can use free services like webhook.site or requestbin.com to test HTTP requests. These services provide example API endpoints so you can validate your requests without actually transferring any data. 

You can also use Postman, a free API client, to explore API endpoints and test HTTP requests. This can be useful for debugging your requests outside of Logic. 

FAQ and troubleshooting

My HTTP request is failing, but I’m not sure why. 

You can rely on response status codes (and, occasionally, the response body) to provide more information about why your HTTP request might be failing — for example, it might be failing due to a client error or a server error. 

If you’re receiving a client error response, your request may be malformed. It may help to validate your JSON with a free tool like JSONLint to resolve any syntax errors. 

You can also test individual Make HTTP request blocks for easier troubleshooting. Learn how to test Make HTTP request blocks. 

If you’re still unsure why your HTTP request is failing, please reach out to the third-party service where you’re sending your request for additional support and resources. 

If you believe you’re experiencing issues with the Make HTTP request block itself, please contact our customer support team for assistance. Please be sure to include your Flow ID with your submission. 

What’s the difference between PUT and PATCH? 

A PUT request will create a new resource if it can’t find the specified resource to update. The PUT request method also replaces the entire requested resource with the data in the request body. This means any unspecified values will overwrite existing values for the resource you update — which can be destructive in some cases. 

With a PATCH request, you can update part of a resource by passing in only the data you want to update. 

Can other Workspace members see any credentials (e.g., third-party API keys, usernames and passwords) I’ve added? 

Workspace members can manage, use, and see portions of credentials. However, once a credential has been created, no one, including the original creator of that credential, can see the actual value of the credential in the Webflow UI. In other words, Workspace members can see the user-defined names for the credentials created, but do not have access to the actual values for API tokens or usernames and passwords.

How does Webflow store and handle credentials? 

Credentials are stored securely — always encrypted in transit and always encrypted at rest. Once a credential has been created, no one, including the original creator of that credential, can see the actual value of the credential in the Webflow UI. You’ll only be able to see the user-defined names for the credentials created. 

Please note that although Webflow stores credentials in a secure way, Webflow does not have control over any server you send the credential to using Logic flows. 

What happens to credentials when a site is cloned or transferred? 

Credentials are not preserved when a site is cloned or transferred. Any credentials used in your flows will need to be recreated after the site has been cloned or transferred.