How to get deploy URL for a scheduled function?

Does anyone know how to get the URL for a deploy for a Netlify Function? I’m calling a background function from a scheduled function, so the scheduled function needs to know the domain of the background function’s URL.

I could hard-code the domain, but then PR deploys and branch deploys will always make a request to the production deployment. I want them to make the request to the PR deploy or branch deploy in which the scheduled function is running (and similarly to localhost:8888 for local dev) – i.e. stay within the same deploy or environment.

For example, when I have the background function and scheduled function deployed from PR 567, I want the scheduled function to make its request to https://deploy-preview-567--my-site.netlify.app/function/my-function-background and when the functions are deployed to production, I want the request to go to https://my-site.netlify.app/function/my-function-background. The path or the URL never changes, but the domain does and I don’t know how to get it at runtime.

It looks like the environment variable DEPLOY_URL is automatically defined when using netlify dev, but not when deployed to production. When deployed to production, Netlify.env.get("DEPLOY_URL") evaluates to undefined.

The below is what Netlify’s AI said to help me with this, but I’m not sure if it’s 100% correct because the docs here don’t agree Environment variables and functions | Netlify Docs . The docs don’t mention DEPLOY_URL or DEPLOY_PRIME_URL.

When deploying functions on Netlify, there are several environment variables available that provide information about the deployment URLs. These variables are particularly useful when you need to reference your site's URL in your functions.

### Deploy URL Environment Variables
Netlify provides the following read-only environment variables related to deployment URLs:

- URL: The primary URL of your site (the production URL)
- DEPLOY_URL: The URL of the specific deploy
- DEPLOY_PRIME_URL: The URL of the current deploy or, for branch deploys and Deploy Previews, the URL of the deploy

These environment variables are automatically set by Netlify and can be accessed in your functions using process.env syntax Get started with Netlify.

### Using Environment Variables in Functions
Here's an example of how to access these environment variables in a Netlify Function:

exports.handler = async () => {
  const siteUrl = process.env.URL;
  const deployUrl = process.env.DEPLOY_URL;
  const deployPrimeUrl = process.env.DEPLOY_PRIME_URL;
  
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: "Deploy URLs",
      siteUrl,
      deployUrl,
      deployPrimeUrl
    })
  };
};

### Automatic Deploy Subdomains
When you set up automatic deploy subdomains for your site, the DEPLOY_PRIME_URL environment variable will update for all relevant deploys Automatic deploy subdomains.

### Environment Variable Scopes
To ensure your environment variables are available to functions, make sure they have the appropriate scope. When creating environment variables using the Netlify UI, CLI, or API, they are available to all scopes by default, including Functions Manage deploys.

Note that environment variables created in a netlify.toml file are not available to the deploy environment, so they won't be accessible in your functions at runtime.

Scheduled Functions always work on published deploy, which is for the most part always going to be your production deploy. So hardcoding should not be an issue.

For other Functions, you can use event.headers.host.

Thanks @hrishikesh. That makes sense. My mistake on bringing in the branch and PR deploy scenarios.

What about testing locally? I’ll need the domain to be localhost:8888 for that, which is obviously different than the production domain.

Is there no way to get the domain and port that netlify dev assigns programmatically in a scheduled function? I’d rather not hard code localhost but especially a port in my code.

event.headers.host should still be usable.

No, Netlify doesn’t provide a way to get the domain and port from netlify dev programmatically in a scheduled function. Best option is to use environment variables instead of hardcoding.

Thanks @hrishikesh and @junaid568 . With your help I found two ways to solve my problem.

  1. event.headers.host (actually had to use event.headers.get("host")) contains the domain and possibly port. When running netlify dev, this evaluates to localhost:8888. When deployed to production, this evaluates to 01234567-89ab-cdef-6789-0123456789ab.netlify.app. The GUID subdomain looks like a globally unique ID for this specific deploy. So this is one option.
  2. The other is to use the value from ctx.site.url. ctx is what I named the second parameter of the handler function. This returns http://localhost:8888 when running netlify dev and the site’s production scheme and domain when running in production. Not sure what this returns if the deploy is a branch or PR deploy.

I will use option 1, but I’m not sure if Netlify wants end users using the GUID subdomain. I couldn’t find any reference to it in the docs.

Thanks all.

-Chris

I’m not sure if I understand your code. The code you posted was:

That code indicates you’re using Functions v1 which uses AWS Lambda syntax. In that, the correct way is event.headers.host.

In your reply, it seems you’re using Functions v2 where the argument is Request which is why you need get(). Please consider posting correct code examples in future.

If you’re confused, I’m sorry. I don’t know if I’m using v1 or v2. And actually the code you’re referencing is code I pasted outputted by Netlify’s AI. I stated that in my message.

Moreover, your tone on this (and several other community threads I’ve read) is a bit frustrating. Very passive aggressive with “please consider posting correct code” implying that I was the problem. I realize customer support can be frustrating, but I expect more from Netlify.

Honestly I tried to bring the friendliness up in my replies, but your tone here and in other threads towards users makes me want to use other platforms.