Set Authentication

Open in CMS

When several APIs share the same credentials, for example all the actions you imported from one OpenAPI schema, you can configure authentication once and apply it to all of them in a single step. This tutorial walks you through Set Authentication on the Custom API page, using the project APIs of Atlas, Kirana Group's operations assistant.


Before you start

  • You have at least one API on the Custom API page, either added by hand (Connect Your API) or from a spec (Import an OpenAPI Schema). Atlas has get_project_status and list_projects.
  • You have the credentials for those APIs: a token, a username and password, a custom header key, or OAuth details.
  • You know how to test and publish changes. See Preview and Publish Changes.

About the sample API: the Kirana Projects API used in these tutorials is a public sample and does not accept credentials. If you send it a Bearer token, it answers 403. Kirana's real Projects API would require a Bearer token, which is the situation this page describes. If you follow along with the sample, click Cancel at the end of Step 3 instead of OK, or set the APIs back to None afterwards.


When to Use This Feature

Use Set Authentication when:

  • You have just imported multiple APIs from an OpenAPI schema and need to add credentials to all of them at once
  • Several existing APIs on your agent use the same token or username and password, and you need to rotate or update that credential
  • You want to apply or remove authentication on a specific set of APIs without editing each one individually

Supported Authentication Types

Auth TypeWhen to use
NonePublic endpoints, no credentials needed. Also removes existing authentication.
BasicAPIs that use a username and password
BearerAPIs secured with a static Bearer token
CustomAPIs with a custom header name (for example X-API-Key)
OauthAPIs secured with OAuth 2.0 (Client Credentials or Google Service Account)

Step 1: Open the Set Authentication Panel

On the Custom API page, click Set Authentication in the row of buttons at the top. The Set Authentication panel opens with the line "Configure an authentication once and apply it to multiple custom APIs at the same time."

Set Authentication panel with the text Configure an authentication once and apply it to multiple custom APIs at the same time, an Authentication section with Auth Type Bearer and a masked Key, a Select APIs to update section with 1 selected, Select All and Clear All buttons, an Uncategorized group with Clear group and get_project_status ticked showing its GET URL, and the buttons Cancel and OK

Step 2: Configure the Authentication

In the Authentication section, choose the Auth Type that matches your API. The fields for that type appear next to it. For Kirana's Projects API, choose Bearer and paste the token into Key. The value is masked as you type.

Auth TypeFields to fill in
BearerKey: the token value
BasicUsername and Password
CustomHeader Name (for example X-API-Key) and Key. qlar sends Header Name: Key with every request.
OauthOAuth Provider (Client Credentials or Google Service Account), Token URL, and the provider's credentials. See Authentication Details Reference.
NoneNo fields. Use it to remove authentication from the selected APIs.

Step 3: Select the APIs and Apply

Under Select APIs to update, tick the APIs that should get this authentication. APIs are grouped by category; APIs without a category are under Uncategorized. The header shows how many are selected, for example (1 selected).

  • Select All ticks every API in the list.
  • Clear All unticks every API.
  • Select group / Clear group next to a category ticks or unticks all APIs in that category.

In the screenshot, get_project_status is ticked. For Atlas, tick list_projects as well, since both call the same API.

Click OK (it is disabled until at least one API is ticked). The CMS warns: "Authentication for 2 custom APIs will be changed. This will overwrite their current authentication configuration. Do you want to continue?" Click Yes.

Note: This overwrites the existing authentication on every selected API. APIs you do not select are left untouched.


Step 4: Save All Changes

The new authentication is only in the form so far. Click Save all changes at the bottom of the Custom API page. The CMS asks Are you sure to save your changes? Click Yes. A message confirms Custom API successfully updated!

The updated authentication is saved as a draft. It reaches real users after you click Publish in the top bar.


Check the result

  1. In the list, the chip next to each updated API now shows the new auth type, for example Bearer instead of None.
  2. Click one of the updated APIs, then Test API. The API Details show the new Authentication. Fill in a sample value, for example KG-2041, and click Call API. A 401 or 403 status usually means the credentials are wrong, or, with the public sample, that the API does not accept credentials at all.
  3. In the preview panel, ask a question that should trigger one of the updated APIs, for example "What is the status of KG-2041?", and confirm that Atlas answers with real data.
  4. Click Publish when everything works. See Preview and Publish Changes.

Authentication Details Reference

Bearer token

FieldDescription
KeyThe full token value (without the Bearer prefix; qlar adds it automatically)

Basic authentication

FieldDescription
UsernameThe account username
PasswordThe account password

Custom header

FieldDescription
Header NameThe HTTP header name your API expects (for example X-API-Key or Authorization)
KeyThe value sent in that header

OAuth 2.0, Client Credentials

FieldDescription
Token URLThe endpoint qlar calls to obtain an access token
Client IDYour OAuth client identifier
Client SecretYour OAuth client secret
ScopesOAuth scopes your API needs (optional). Type each scope and press Enter.

OAuth 2.0, Google Service Account

FieldDescription
Token URLFilled in for you (https://oauth2.googleapis.com/token)
Google Service Account JSONThe key file of your service account from Google Cloud Console
API ScopesThe Google API scopes the token should cover
User Delegation (Optional)The email of the user to impersonate. Required for Gmail APIs, optional for Calendar APIs.

Next steps