# Is settings the baseUrl via config in @source supported?

**URL:** https://community.apollographql.com/t/is-settings-the-baseurl-via-config-in-source-supported/8997
**Category:** Connectors
**Tags:** connectors
**Created:** [April 30, 2025, 9:21pm UTC](https://community.apollographql.com/t/is-settings-the-baseurl-via-config-in-source-supported/8997 "2025-04-30T21:21:17Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![andywgarcia](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/andywgarcia/32/5651_2.png) [@andywgarcia](https://community.apollographql.com/u/andywgarcia)
#### Post date: [April 30, 2025, 9:21pm UTC](https://community.apollographql.com/t/is-settings-the-baseurl-via-config-in-source-supported/8997/1 "2025-04-30T21:21:17Z")

</div>

I want to set the baseUrl in the `@source` directive via an environment config setting because we promote our schema from lower environments to upper environments, and the URL for the API changes in each environment. However, we also require schema proposals for all changes, so the baseUrl must be configurable outside the schema. I was thinking I could do the following with the `{$config.myApiBaseUrl}` inside the `@source` directive:

```auto
extend schema
  @link(
    url: "https://specs.apollo.dev/federation/v2.10"
    import: ["@key", "@policy"]
  )
  @link(
    url: "https://specs.apollo.dev/connect/v0.1"
    import: ["@connect", "@source"]
  )
  @source(
    name: "myApi"
    http: {
      baseURL: "{$config.myApiBaseUrl}"
    }
  )

type Account @key(fields: "id") {
  id: ID!
  firstName: String
    @connect(
      source: "/myApi"
      http: { GET: "/accounts/{$this.id}" }
      selection: """
      firstName
      """
    )
}

```

However, I get the following error during composition:

`The value "{$config.myApiBaseUrl}" for `@source(baseURL:)` is not a valid URL: relative URL without a base.(INVALID_URL)`

Is there something I am missing?

---

<div class="post-metadata">

### Author: ![dylan](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/dylan/32/6009_2.png) [@dylan](https://community.apollographql.com/u/dylan)
#### Post date: [April 30, 2025, 9:27pm UTC](https://community.apollographql.com/t/is-settings-the-baseurl-via-config-in-source-supported/8997/2 "2025-04-30T21:27:22Z")

</div>

You can achieve this with a [dedicated setting in router config](https://www.apollographql.com/docs/graphos/connectors/router#overriding-baseurl-for-environment-specific-api-hosts)!

```yaml
connectors:
  sources:
    your-subgraph-name.myApi:
      override_url: "https://value-for-this-environment"

```

You will still need a placeholder or default value in the `@source`, though.

---

<div class="post-metadata">

### Author: ![andywgarcia](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/andywgarcia/32/5651_2.png) [@andywgarcia](https://community.apollographql.com/u/andywgarcia)
#### Post date: [April 30, 2025, 9:35pm UTC](https://community.apollographql.com/t/is-settings-the-baseurl-via-config-in-source-supported/8997/3 "2025-04-30T21:35:41Z")

</div>

Thank you. This is what I needed.

That being said, it is a bit weird that we commit a URL directly into the schema file when the true value really comes from the config in the router.

It would be nice to make that config variable available in the directive so that it is clear to other engineers looking at the schema where that value comes from

---

<div class="post-metadata">

### Author: ![dylan](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/dylan/32/6009_2.png) [@dylan](https://community.apollographql.com/u/dylan)
#### Post date: [April 30, 2025, 10:24pm UTC](https://community.apollographql.com/t/is-settings-the-baseurl-via-config-in-source-supported/8997/4 "2025-04-30T22:24:48Z")

</div>

Agreed, and we definitely want to make base URLs be more dynamic using the same expressions as `@connect`! We just have to work through a few details, since there are some extra security implications when domains can be dynamically modified.
