@vercel/functions API Reference (Node.js)
- Install the package:
- Import the package (non-Next.js frameworks or Next.js versions below 15.1):
For OIDC methods, import
If you’re using Next.js 15.1 or above, we recommend using the built-in function from instead of .
allows you to schedule work that runs after the response has been sent or the prerender has completed. This is especially useful to avoid blocking rendering for side effects such as logging, analytics, or other background tasks.
- does not block the response. The callback runs once rendering or the response is finished.
- is not a Dynamic API; calling it does not cause a route to become dynamic.
- If you need to configure or extend the timeout for tasks, you can use in Next.js.
- For more usage examples (including in Server Components, Server Actions, or Middleware), see after() in the Next.js docs.
If you're not using Next.js 15.1 or above (or you are using other frameworks), you can use the methods from below.
Description: Extends the lifetime of the request handler for the lifetime of the given Promise. The method enqueues an asynchronous task to be performed during the lifecycle of the request. You can use it for anything that can be done after the response is sent, such as logging, sending analytics, or updating a cache, without blocking the response. is available in Node.js and in the Edge Runtime.
Promises passed to will have the same timeout as the function itself. If the function times out, the promises will be cancelled.
Description: Gets the System Environment Variables exposed by Vercel.
Description: Returns the location information for the incoming request, in the following way:
Description: Returns the IP address of the request from the headers.
Description: Marks a cache tag as stale, causing cache entries associated with that tag to be revalidated in the background on the next request.
| Name | Type | Description |
|---|---|---|
| or | The cache tag (or multiple tags) to invalidate. |
Description: Marks a cache tag as deleted, causing cache entries associated with that tag to be revalidated in the foreground on the next request. Use this method with caution because one tag can be associated with many paths and deleting the cache can cause many concurrent requests to the origin leading to cache stampede problem. A good use case for deleting the cache is when the origin has also been deleted, for example it returns a or status code.
| Name | Type | Description |
|---|---|---|
| or | The cache tag (or multiple tags) to dangerously delete. | |
| The time in seconds before the delete deadline. If a request is made before the deadline, it will revalidate in the background. Otherwise it will be dangerously deleted and revalidate in the foreground. |
Description: Marks all cached content associated with a source image as stale, causing those cache entries to be revalidated in the background on the next request. This invalidates all cached transformations of the source image.
Learn more about purging Vercel cache.
| Name | Type | Description |
|---|---|---|
| The source image to invalidate. |
Description: Marks all cached content associated with a source image as deleted, causing those cache entries to be revalidated in the foreground on the next request. Use this method with caution because deleting the cache can cause many concurrent requests to the origin leading to cache stampede problem. A good use case for deleting the cache is when the origin has also been deleted, for example it returns a or status code.
Learn more about purging Vercel cache.
| Name | Type | Description |
|---|---|---|
| The source image to dangerously delete. | ||
| The time in seconds before the delete deadline. If a request is made before the deadline, it will revalidate in the background. Otherwise it will be dangerously deleted and revalidate in the foreground. |
Description: Adds one or more tags to a cached response, so that you can later invalidate the cache associated with these tag(s) using .
| Name | Type | Description |
|---|---|---|
| or | One or more tags to add to the cached response. |
- A cached response can have a maximum of 128 tags.
- The maximum tag length is 256 bytes (UTF-8 encoded).
- Tag names cannot contain commas.
Description: Returns a object that allows you to interact with the Vercel Runtime Cache in any Vercel region. Use this for storing and retrieving data across function, routing middleware, and build execution within a Vercel region.
| Name | Type | Description |
|---|---|---|
| Optional custom hash function for generating keys. | ||
| Optional namespace to prefix cache keys. | ||
| Optional separator string for the namespace. |
provides the following methods:
| Method | Description | Parameters |
|---|---|---|
| Retrieves a value from the Vercel Runtime Cache. | : The cache key | |
| Stores a value in the Vercel Runtime Cache with optional and/or . The option allows a human-readable label to be associated with the cache entry for observability purposes. |
| |
| Removes a value from the Vercel Runtime Cache by key | : The cache key to delete | |
| Expires all cache entries associated with one or more tags | : Tag or array of tags to expire |
After assigning tags to your cached data, use the method to invalidate all cache entries associated with that tag. This operation is propagated globally across all Vercel regions within 300ms.
The Runtime Cache is isolated per Vercel project and deployment environment ( and ). Cached data is persisted across deployments and can be invalidated either through time-based expiration or by calling . However, TTL (time-to-live) and tag updates aren't reconciled between deployments. In those cases, we recommend either purging the runtime cache or modifying the cache key.
The Runtime Cache API does not have first class integration with Incremental Static Regeneration. This means that:
- Runtime Cache entry tags will not apply to ISR pages, so you cannot use expireTag to invalidate both caches.
- Runtime Cache entry TTLs will have no effect on the ISR revalidation time and
- Next.js's and API does not invalidate the Runtime Cache.
The following Runtime Cache limits apply:
- The maximum size of an item in the cache is 2 MB. Items larger than this will not be cached.
- A cached item can have a maximum of 128 tags.
- The maximum tag length is 256 bytes.
Usage of the Vercel Runtime Cache is charged, learn more about pricing in the regional pricing docs.
Call this function right after creating a database pool to ensure proper connection management in Fluid Compute. This function ensures that idle pool clients are properly released before functions suspend.
Supports PostgreSQL (pg), MySQL2, MariaDB, MongoDB, Redis (ioredis), Cassandra (cassandra-driver), and other compatible pool types.
| Name | Type | Description |
|---|---|---|
| The database pool object. |
This function has moved from @vercel/functions/oidc to @vercel/oidc-aws-credentials-provider. It is now deprecated from @vercel/functions and will be removed in a future release.
Description: Obtains the Vercel OIDC token and creates an AWS credential provider function that gets AWS credentials by calling the STS API.
| Name | Type | Description |
|---|---|---|
| ARN of the role that the caller is assuming. | ||
| Custom STS client configurations overriding the default ones. | ||
| Custom STS client middleware plugin to modify the client default behavior. | ||
| A function that assumes a role with web identity and returns a promise fulfilled with credentials for the assumed role. | ||
| An identifier for the assumed role session. | ||
| The fully qualified host component of the domain name of the identity provider. | ||
| ARNs of the IAM managed policies that you want to use as managed session policies. | ||
| An IAM policy in JSON format that you want to use as an inline session policy. | ||
| The duration, in seconds, of the role session. Defaults to 3600 seconds. |
This function has moved from @vercel/functions/oidc to @vercel/oidc. It is now deprecated from @vercel/functions and will be removed in a future release.
Description: Returns the OIDC token from the request context or the environment variable. This function first checks if the OIDC token is available in the environment variable . If it is not found there, it retrieves the token from the request context headers.
Was this helpful?