Skip to main content

Custom Tenant URLs

Brand your Tines tenant with a custom URL

Jamie Gaynor avatar
Written by Jamie Gaynor
Updated over a week ago

Overview

Tines supports custom tenant URLs, allowing you to change from the default format like silent-beach-3471.tines.com to a custom domain like acme.tines.com.

Should you choose to do this, this guide outlines what you will need to be aware of, how to prepare, and best practices for a smooth transition.

Notes:

  1. This is only for Business and Enterprise edition tenants

  2. To change your tenant name or request a custom domain, reach out to your CSM, CSE or Tines Support, and they will go through the process of setting one up with you.

Important to know:

  • Webhook URLs - External systems sending webhooks will fail

  • OAuth Credentials - Callback URLs will need immediate updates

  • SSO Configuration - This may break; please disable before migration OR create recovery codes

  • Published Pages - All shared page links will break

  • API Endpoints - Scripts/integrations using Tines API will fail

  • Email Actions - Stories with hardcoded tenant URLs in emails

Both disabling SSO and creating login recovery codes are done in Tines.

Backwards Compatibility

There's an option to keep your old domain temporarily active. This will allow webhooks and pages to keep working with your old URLs.

However, your SSO and OAuth will still require updates.

We recommend fully migrating within 30-60 days of your new tenant URL being deployed

Pre-Migration Checklist:

We recommend following these suggested steps for a successful migration.

1 week before:

  • Audit all systems sending webhooks to Tines

  • Document published pages shared externally

  • Identify scripts/tools using Tines API

  • Search stories for hardcoded URLs

  • List all OAuth credentials

  • Notify users of migration timing

3 days before:

  • Decide on your SSO approach (disable or create recovery codes)

  • Plan out your OAuth callback updates

  • Schedule during low-activity period

Migration Day:

  1. Disable SSO or create recovery codes

  2. Execute domain change + enable backwards compatibility

  3. Immediately update OAuth callbacks and test

  4. Update SSO config and re-enable

  5. Test critical workflows

Steps on disabling and enabling SSO can be found here.

Steps on changing your domain name can be found here.

Read more about OAuth here.

Next steps:

  • Update external webhook senders

  • Redistribute new page URLs

  • Update API integrations

  • Monitor errors daily

Key Tips

Do:

  • Enable backwards compatibility for transition

  • Migrate during off-hours

  • Test SSO/OAuth immediately after

  • Allow 30 days for full migration

Don't:

  • Disable backwards compatibility until everything is updated

  • Skip user communication

Need help

If something isn’t working or you need help with any of the above steps, please contact support.

Did this answer your question?