Migrating to account-specific access URLs
Account-specific access URLs are being assigned to dbt accounts as part of our ongoing efforts to improve your experience and strengthen security. Each account will receive its own unique dbt platform and API access URLs on the dbt.com domain rather than sharing generic getdbt.com region URLs. For example:
- Old:
https://cloud.getdbt.com - New:
https://ab123.us1.dbt.com
What does this mean for me?
If your account has been assigned a new access URL, please review the migration timeline and update your account's external integrations using the integration checklist.
If your account has not been assigned a new access URL, you will receive an email and in-app notification with a scheduled enablement date. When the change takes effect, you'll be automatically redirected to your dbt.com account-specific access URL. Account sign-in remains the same. Both the new dbt.com and getdbt.com region URLs will support integrations according to the dates on the migration timeline.
Before assignment, if your organization uses network allowlisting, add the dbt.com domain to your allowlists. For single-tenant accounts, there will be no change to IP addresses. For multi-tenant accounts, refer to Access, Regions, & IP addresses for updated IPs. If your account has IP restrictions enabled, review Validating IP restrictions before your assignment date.
Migration timeline
Accounts across all regions and service providers are being assigned new access URLs. getdbt.com region URLs will continue to support integrations until the scheduled deprecation date, unless otherwise specified.
| Stage | Status | Timeline |
|---|---|---|
| Multi-tenant dbt.com access URL assignment | ✅ Completed | January 2026 |
| Single tenant dbt.com access URL assignment | In Progress | April - September 2026 |
| getdbt.com region URL deprecation | Scheduled | February 3, 2027 (previously November 1, 2026) |
Integration checklist
Review the following checklist before the getdbt.com region URL deprecation date documented in the migration timeline. Update each integration that uses a dbt access URL. If your integration isn't in this list, please speak with your IT or applicable team to identify whether you need to take action.
dbt Labs updates the dbt GitHub application, the Slack application, and GitLab webhooks automatically. Inbound Azure DevOps service hooks are not included.
Identity and access management
| Integration | Action required |
|---|---|
| Google Workspace SSO | Update or add an OAuth client |
| SCIM (Okta) | Update the SCIM base URL in Okta |
Git providers
GitLab and Azure DevOps repositories connected before your account had an account-specific access URL keep using your legacy getdbt.com URL for OAuth until you update them. Repositories connected after that already use your new access URL.
For GitLab, account admins can update an existing GitLab application to your new account access URL in dbt platform. See Update redirect URIs in dbt platform. You can't yet update an existing Azure DevOps repository. Instead, recreate the repository to generate a redirect URI based on your new account access URL.
| Integration | Action required |
|---|---|
| GitLab (dbt Labs app) | Add the new redirect URI to your GitLab group application, then update it in dbt platform |
| GitLab (bring-your-own app) | Add the new redirect URI to your GitLab group application, then update it in dbt platform |
| Azure DevOps (service principal) | Update or add an app registration |
| GitHub On-premises | Contact dbt Labs Support |
Data platform connections
Data platform connections created before your account had an account-specific access URL keep using your legacy getdbt.com URL for OAuth until you update them. Connections created after that already use your new access URL, so they need no changes.
Account admins can update older Snowflake, Databricks, and BigQuery OAuth connections to your new access URL directly in dbt platform. See Update redirect URIs in dbt platform.
| Integration | Action required |
|---|---|
| Snowflake OAuth | Add the new redirect URI to your security integration, then update it in dbt platform |
| Snowflake External OAuth | Update the redirect URI in your IdP application |
| Databricks OAuth | Add the new redirect URI to your Databricks OAuth app, then update it in dbt platform |
| BigQuery OAuth | Add the new redirect URI to your Google Cloud OAuth client, then update it in dbt platform |
| Redshift External OAuth | Update the redirect URI in your IdP application |
Update redirect URIs in dbt platform
If your account has an account-specific access URL, dbt platform flags each Snowflake, Databricks, or BigQuery OAuth connection and GitLab application that still uses a legacy redirect URI. Updating connections requires the Account Admin or Project Creator permission set. Updating a GitLab application requires the Account Admin permission set.
- In dbt platform Account settings, go to Connections (or Integrations for GitLab) and select a flagged item. The page shows the new redirect URI.
- Add the new redirect URI to the OAuth configuration in your data platform or GitLab, alongside the existing one. The existing URI keeps working until you remove it.
- In dbt platform, click Update redirect URI.
- Test data platform connections by signing in again from your development credentials. For GitLab, repeat the personal GitLab authorization flow from Account settings > Personal profile > Linked accounts. Confirm that the relevant OAuth flow returns successfully to dbt platform before removing the old redirect URI.
Updating the redirect URI doesn't interrupt active sessions. The new URI takes effect the next time a session expires and the user signs in again.
If sign-in fails after the update, you have 7 days to roll back this change. Open the connection or GitLab application and click Revert to previous URI to restore the previous redirect URI while you troubleshoot. After you confirm that every integration works with the new URI, remove the old URI from your data platform or GitLab.
If several connections share one OAuth app, add the new redirect URI once to that app, then update each connection in dbt platform.
Network and API
| Integration | Action required |
|---|---|
| Network allowlists | Add new access URLs to your allowlist policies |
| Inbound webhooks | Update access URLs in your webhook configurations |
| API integrations | Update access URLs in your API clients |
| Terraform provider | Update access URLs in your Terraform configuration |
| Browser bookmarks | Update personal and shared bookmarks |
Validating IP restrictions
If you've received notification of a new access URL assignment and have IP restrictions enabled, review the network rules that point specifically at your *.getdbt.com domain. These include VPN split-tunneling rules, proxy (PAC) rules, and firewall egress rules. Update these rules for your new *.dbt.com access URL before your account's scheduled assignment date so access isn't disrupted.
To confirm your new access URL is accessible, send a test request from the same network you'd normally use to reach your *.getdbt.com URL. Replace NEW_ACCESS_URL with your account's new access URL and ACCOUNT_ID with your account ID:
- Browser: Go to
https://NEW_ACCESS_URL/api/v2/accounts/ACCOUNT_ID/ - Terminal: Run
curl -s https://NEW_ACCESS_URL/api/v2/accounts/ACCOUNT_ID/
| Result | Response detail | What it means |
|---|---|---|
| ✅ Passed | { ... "detail": "Authentication credentials were not provided." ... } | The request reached the API and passed IP restrictions. There's no authenticated session, which is expected for this test. |
| ⚠️ Blocked | { ... "user_message": "Forbidden: Access denied" ... } | The request's IP address isn't on your allowlist. Update your network egress rules for the new access URL and test again. |
FAQs
For questions or assistance, contact dbt Labs Support.
Was this page helpful?
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
