Last modified: November 18, 2025
App cards can be built to request data from an external source using the hubspot.fetch() API. At a high level, to fetch data using this method, you’ll need to:
- Provide a REST-based back-end service to handle requests.
- Include the request URLs as
permittedUrlsin the app’s configuration.
hubspot.fetch() are subject to the following limits:
- Each app is allowed up to 20 concurrent requests per account that it’s installed in. Additional requests will be rejected with the status code
429, and can be retried after a delay. - Each request has a maximum timeout of 15 seconds. Both request and response payloads are limited to 1MB. You can specify a lower timeout per request using the
timeoutfield. Request duration time includes the time required to establish an HTTP connection. HubSpot will automatically retry a request once if there are issues establishing a connection, or if the request fails with a5XXstatus code within the 15 second window.
hubspot.fetch() API along with examples.
Method
The method contract forhubspot.fetch() is as follows:
| Parameter | Type | Description |
|---|---|---|
method | String | The method to use. |
timeout | Number | Time in milliseconds to allow for the request to complete before timing out. Timeout will occur when the back-end request duration exceeds this value or 15 seconds—whichever is smaller. Request duration time includes the time required to establish an HTTP connection.HubSpot will retry a request once if there are issues establishing a connection, or if the request fails with a 5XX status code within the 15 second window. |
body | Object | The request body. |
Specify URLs to fetch from
To make calls to your backend or a third-party service, update the app’s*-hsmeta.json configuration file to include the URLs you’ll be requesting. The URLs must be specified in the fetch array of permittedUrls.
Note that fetch URLs must be valid HTTPS URLs and cannot be localhost. If you want to send requests to a locally running back-end, learn how to proxy requests.
Headers and metadata
To ensure that the requests hitting your back-end are coming from HubSpot, several headers are included in the request. You can use these headers, along with the incoming request fields, to verify the signature of the request. Learn more about validating HubSpot requests. HubSpot will always populate headers related to request signing and also allow you to pass anAuthorization header from hubspot.fetch(). See the example hubspot.fetch() request with Authorization header for more information.
HubSpot also automatically adds the following query parameters to each request to supply metadata: userId, portalId, userEmail, and appId. As the request URL is hashed as part of the signature header, this will help you securely retrieve the identity of the user making requests to your back-end.
Proxying requests to a locally running back-end
If you have a locally running back-end, you can set up a proxy to remaphubspot.fetch() requests made during local development. This proxy is configured through a local.json file in your project, and will prevent requests from being routed through HubSpot’s data fetch service.
To proxy requests to a locally running back-end:
- Create a
local.jsonfile in the same directory as yourpublic-app.jsonfile. In this file, define a proxy that remaps requests made usinghubspot.fetch(). This mapping will only happen for the locally running extension. You can include multiple proxy key-value pairs in theproxyobject.
-
Upload your project by running
hs project upload. -
With your project uploaded, run
hs project devto start the development server. The CLI should confirm that it has detected your proxy.
-
When you request the mapped URL using
hubspot.fetch(), the CLI will confirm the remapping.
Request signatures during proxied local development
By default, when proxying requests during local development, requests will not be signed or include metadata in query parameters. However, if you want to introduce request signing into the local development process, you can inject theCLIENT_SECRET environment variable into the local development process.
Injecting CLIENT_SECRET
After setting up yourlocal.json file to proxy specific domains, you can inject the CLIENT_SECRET variable when starting the local development server by prepending the hs project dev command with the variable:
CLIENT_SECRET value, as long as you inject the same variable in your locally running back-end that you’re using for hs project dev. For example, your back-end might include the following Node or Python code:
CLIENT_SECRET variable:
CLIENT_SECRET variable from your app into the hs project dev command permanently. For ease of use, consider baking the variable into your start scripts for local development.
To validate HubSpot request signatures in your custom back-end, check out the request validation guide. You can also use HubSpot’s @hubspot/api-client npm module to verify requests and sign them yourself. For example:
hubspot.fetch examples
Below are examples ofhubspot.fetch requests to illustrate promise chaining, async/await, and authorization header usage.
Promise chaining
Async/await
Authorization header
You may return a short-lived authorization token from your back-end service after validating the HubSpot signature. You can then use this token to access other resources. To get the access token from your back-end server in the UI extension:Monitoring and logs
To monitor app card activity, you can view request logs in HubSpot:- In your HubSpot account, navigate to Development.
- In the left sidebar, navigate to Monitoring > Logs.
- On the monitoring page, click the UI Extensions tab.
- Extension Render: logs related to the app card loading in its configured location.
- hubspot.fetch(): logs related to
hubspot.fetch()requests. - Extension Log: [custom messages logged](## Send custom log messages for debugging) by the app card using
logger.debug.
To view more information about a log entry, click the ellipsis button in the Actions column of the row, then select Open details. In the right sidebar, you can review the details for the entry and use the provided IDs for deeper debugging.