Configure Xkit Settings

In order to use Xkit successfully with your app, you'll need to configure a few settings. To view the settings, click on "Settings" on the left-hand menu, or just follow this link: Settings.

Display Name

The Display Name controls how your Application is presented to users on pages that Xkit renders, like the Integration Catalog.

This should be a bare name, like "My App", not a name specific for Xkit, like "My App Integrations".

URL Slug

This is the primary identifier for your application, and forms the subdomain of xkit.co that you'll use as your Hosted Integration Catalog and as the host when using the Platform User API.

❗️

Change this value with extreme caution

Changing the URL Slug will:

• Invalidate all Xkit User Tokens
• Invalidate all user sessions
• Break links to the Hosted Integration Catalog
• Break API calls to the Platform User API
• Break redirect URLs with OAuth providers

Custom Domain

In cases where you don't want to use a subdomain of Xkit and would rather use your own domain (e.g. integrations.example.com), you can do so with the Custom Domain feature. Since in addition to being the location of the Hosted Integration Catalog and the domain for the Platform User API, it also forms the base of the redirect URLs used in schemes like OAuth, it may be desirable (or necessary) to have those be on a domain controlled by your company.

Custom domains are a paid feature, so if you need access to it, please Contact Support.

❗️

Change this value with extreme caution

Change the custom domain will:

• Invalidate all Xkit User Tokens
• Break redirect URLs with OAuth providers

To set up a custom domain, follow these steps:

1. Add a CNAME record with your DNS provider pointing your desired custom domain (e.g. integrations.example.com) to secure.xkit.co
2. Add your desired custom domain (e.g. integrations.example.com) to the Custom Domain field in the Application Settings of Settings page
3. Update all instances of your Xkit slug (e.g. example.xkit.co) to your custom domain (e.g. integrations.example.com) including:
   • the domain you retrieve the xkit.js and xkit-catalog.js scripts
   • the domain you use to initialize the xkit.js npm package
   • all redirect URLs with OAuth providers

From now on, your custom domain will be the primary identifier for your Xkit installation.

🚧

Turn off Cloudflare Proxy

If you use Cloudflare as your DNS provider, make sure to turn the "Proxy Status" to "DNS Only". Otherwise your custom domain will not work.

Website Origin

To protect users against certain types of malicious behavior, Xkit uses CORS headers to limit the origins which can call the Platform User API.

Add the origin (hostname and protocol, like https://example.com) of the website where you will use xkit.js, host your own integration catalog, or otherwise call the Platform User API in order to add it to the allowlist.

Xkit automatically adds the domain with the URL slug and your custom domain (if defined) to the list of valid web origins.

The origins can use wildcard patterns. For example, the pattern https://app-*.example.com would match https://app-production.example.com and https://app-staging.example.com.

The origins can also be managed via the Platform API.

Login Redirect URL

In cases where a user visits the Xkit Hosted Integration Catalog and is not signed into Xkit, or when you use xkit.js to call an authenticated endpoint with a logged-out user, the user will be redirected to this URL to login.

API Keys

See the Platform API Authentication Guide for more information on how to use API Keys.

See the Xkit User Tokens Guide for more information about User Token settings.