Security and Control - Kore.ai Docs

Configure authentication, authorization, encryption, API access control, and custom scripts for your Agent Platform account.

Feature	Description
Authentication Settings	Authenticate users through an external Identity Provider using SAML, WS-Federation, or OpenID Connect
Authorization Profiles	Define how the Platform authenticates with external web services using OAuth and other token-based methods
Encryption Key Management	Configure Platform-managed or bring-your-own-key (BYOK) encryption for account data
API Scopes	Create permission-limited API keys scoped to specific endpoints and integrations
Custom Scripts	Import, deploy, and manage custom scripts in isolated containers via API or tool flows

Authentication Settings

Authentication Settings lets administrators configure how users sign in to the Platform. You can enable Single Sign-On (SSO) to authenticate users through your organization’s identity provider, and Multi-Factor Authentication (MFA) to add a second layer of verification for email/password sign-ins.

Only account owners and admins can configure Authentication Settings.

How SSO and MFA Work Together

The Platform supports two authentication paths, and MFA scope adjusts automatically based on which path is active:

Authentication State	Who Signs In Via Email/Password	MFA Managed By
SSO Disabled	All users	Platform (applies organization-wide)
SSO Enabled	SSO-excluded users only	Platform (applies to excluded users only); the Identity Provider (IdP) manages all other users’ MFA

Access Authentication Settings

Log in to your account and select Settings on the top navigation bar.
In the left menu, go to Security & Control > Authentication Settings.

The page is divided into two sections:

Single Sign-On (SSO) Configuration
Multi-Factor Authentication (MFA).

Single Sign-On (SSO)

SSO allows users to access their Platform accounts using credentials managed by an external IdP. Once authenticated with the IdP, users can access the Platform without a separate login. Key benefits:

Secure Access - Reduces password fatigue and the risk of phishing or weak passwords.
Simplified User Management - Centrally grant or revoke access across all users.
Improved User Experience - Eliminates repeated logins within the same session.
Centralized Access Control - Enforce and monitor security policies across all applications from one place.

Supported SSO Protocols and Providers

Protocol	Providers
SAML 2.0	Okta, OneLogin, Other Provider
WS-Federation	Windows Azure, Other Provider
OpenID Connect	Google

How SSO Works

User attempts to access their account.
The Service Provider (SP) redirects the user to the IDP login page.
User authenticates with the IDP.
IDP issues an authentication token.
SP validates the token and grants access.
User accesses the account without re-authenticating for the rest of the session.

SSO Status

The SSO Status toggle at the top of the SSO Configuration section controls whether SSO is active for your organization.

Toggle State	Behavior
SSO Disabled (default)	All users authenticate via email and password. The SSO Protocol, Identity Provider, and SSO-Excluded Users sections are hidden.
SSO Enabled	Users authenticate through the configured identity provider. The SSO Protocol, Identity Provider, and SSO-Excluded Users sections appear.

Enable SSO

On the Single Sign-On page, select Enable SSO.
Select a Sign-on protocol and SSO provider.
Enter the configuration parameters for your selected protocol and provider (see Configuration Parameters).
Add at least one SSO-excluded user (see SSO-Excluded Users).
Select Save.

Disable SSO

Disabling SSO collapses the SSO Protocol, Identity Provider, and SSO-Excluded Users sections, and reverts all users to email/password authentication. The MFA section updates automatically to reflect organization-wide scope. Steps:

Go to Security & Control > Authentication Settings.
Under SSO Status, toggle off SSO Enabled (it will show SSO Disabled).
In the confirmation dialog, select Yes to confirm.

Previously configured SSO parameters are retained and visible if you re-enable SSO.

SSO-Excluded Users

When SSO is enabled, all users must sign in through the configured IdP by default. Use this section to designate specific users who can bypass SSO and sign in via email/password instead - useful when the SSO provider is unavailable, misconfigured, or the certificate has expired.

The account owner is excluded by default. It is strongly recommended to exclude at least one additional admin user as a fallback.

Add an Excluded User

Enter a valid email address in the Add User Email field.
Select Add User. The user appears as a chip in the Excluded Users list.
Select Save.

Sign-In Flow for Excluded Users Excluded users can sign in via email/password even when SSO is enabled. If MFA is configured, they’re prompted to complete verification before access is granted.

Configuration Parameters

SAML

Provider	Required Parameters
Okta	Okta Single Sign-On URL - SSO endpoint for SP-initiated flow Identity Provider Issuer - Entity URL that authenticates users Certificate - Public certificate to validate user signatures (up to 2)
OneLogin	SAML 2.0 Endpoint - SSO endpoint for SP-initiated flow Issuer URL - Same role as Identity Provider Issuer (Okta) X.509 Certificate - Same role as Certificate (Okta)
Other	Single Sign-On URL - IDP SSO endpoint Issuer URL - Same role as Identity Provider Issuer (Okta) Certificate - Same role as Certificate (Okta)

WS-Federation

Provider	Required Parameters
Windows Azure	Azure AD Sign-On Endpoint URL - URL for sign-on/sign-off requests; responses go to the Reply URL in your Azure AD config Azure AD Federation Metadata Document - URL for the federation metadata document
Other	AD Sign-On Endpoint URL - Same role as Azure AD Sign-On Endpoint URL AD Federation Metadata Document URL - Same role as Azure AD Federation Metadata Document

OpenID Connect

Provider	Required Parameters
Google	None - users authenticate with their existing Google credentials

When multiple certificates are added, the system uses the most recent valid one. If it’s invalid, it automatically falls back to other available certificates.

Multi-Factor Authentication (MFA)

MFA adds a second layer of verification during sign-in for users who authenticate via email/password. The Platform supports the following MFA methods: Email Verification, Authenticator App (TOTP), and SMS.

Enable MFA

Go to Security & Control > Authentication Settings.
Under MFA Status, toggle MFA Required.
Under Allowed MFA Methods, select the methods to enable - Email Verification, Authenticator App, or SMS.
Select Save.

Disable MFA

Under MFA Status, toggle off MFA Required (it will show MFA Disabled).
Select Save.

When MFA is enabled and a user signs in for the first time:

The user enters their email address and password.
The Platform prompts the user to set up an MFA method.
On subsequent logins, the user is prompted to enter their MFA verification code.
On successful verification, access is granted.

SSO Protocol Reference

SAML 2.0

Security Assertion Markup Language (SAML) is a protocol for web-based SSO that uses secure tokens instead of passwords. It allows IDPs and SPs to operate separately. When a user logs into a SAML-enabled app, the service provider requests authorization from the IDP, which authenticates the user and grants access to the application.

How SAML works

SAML SSO works by transferring the user’s identity from one place (the IDP) to another (the SP) through an exchange of digitally signed XML documents. When a user logs into a system that acts as an IDP and tries to access his Platform account, the following happens:

The user accesses the remote app on the IDP portal using the sign-on endpoint URL, and the application loads.
The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the IDP, asking for authentication. This is the authentication request.
The user either has an existing active browser session with the IDP or establishes one by logging into the IDP.
The IDP builds the authentication response in an XML document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the SP.
The SP, which knows the IDP and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
The user’s identity is established, and the user is provided with the Platform account access.

Okta

Go to Single Sign-On → Enable SSO → select SAML and Okta.
In the Okta Developer Portal, go to Applications → Create App Integration → select SAML 2.0 → select Next.
Enter an App Name under General Settings → select Next.
Under Configure SAML, paste values from the Platform’s SSO page:
- ACS URL for SP-initiated SAML flow → Single Sign-On URL
- ACS URL for IDP-initiated SAML flow → Audience URI (SP Entity ID)
Select Next → Finish.
On the Sign On tab, select View Setup Instructions and copy:
- Identity Provider Single Sign-On URL → paste into Okta Single Sign-On URL on the Platform
- Identity Provider Issuer → paste into Identity Provider Issuer on the Platform
Go to Sign On → SAML Signing Certificates → select Download certificate under Actions.
Open the certificate in a text editor and copy the data between BEGIN CERTIFICATE and END CERTIFICATE.
Paste the value into the Certificate field on the Platform’s SSO page. To add a second certificate, select + Add New.
Select Save.

OneLogin

Go to Single Sign-On → Enable SSO → select SAML and OneLogin.
In the OneLogin Developer Portal, go to Applications → Add Apps, search for your Platform app, and save it.
From SSO → Enable SAML 2.0, copy:
- OneLogin SAML 2.0 Endpoint (HTTP) → paste into SAML 2.0 Endpoint on the Platform
- OneLogin Issuer URL → paste into Issuer URL on the Platform
Select View Details on the X.509 Certificate field → copy the certificate data (between BEGIN CERTIFICATE and END CERTIFICATE).
Paste into the X.509 Certificate field on the Platform’s SSO page. To add more, select + Add New.
Copy ACS URL for SP-initiated SAML flow and ACS URL for IDP-initiated SAML flow from the Platform and paste them into the corresponding fields in OneLogin.
Select Save in both the Platform and OneLogin.

Other SAML Providers

Go to Single Sign-On → Enable SSO → select SAML and Other.
Fetch the SSO configuration parameters from your IDP’s developer portal.
Paste the values into the relevant fields on the Platform’s SSO page.
Copy ACS URL for SP-initiated SAML flow and ACS URL for IDP-initiated SAML flow from the Platform and paste them into your IDP app settings.
Select Save.

WS-Federation

WS-Federation enables SSO by sharing signed security tokens across different domains. After the IDP authenticates the user, it issues a token that the relying party validates before granting access.

Windows Azure

Go to Single Sign-On → Enable SSO → select WS-Federation and Windows Azure.
On your AD FS server, open AD FS Management → go to ADFS → Service → Endpoints → Metadata to locate the Federation Metadata URL.
Copy the IdP URL from the metadata and paste it into Azure AD Sign-On Endpoint URL on the Platform.
Paste the Azure Federation Metadata URL into Azure AD Federation Metadata Document on the Platform.
Select Save.

Other WS-Federation Providers

Go to Single Sign-On → Enable SSO → select WS-Federation and Other.
Copy the SSO endpoint URL from your IDP and paste it into AD Sign-On Endpoint URL.
Copy the WS-Federation metadata document URL from your IDP and paste it into AD Federation Metadata Document URL.
Select Save.

OpenID Connect

OpenID Connect (OIDC) is an authentication layer built on OAuth 2.0. The Platform supports Google as the OIDC provider.

Google

Go to Single Sign-On → Enable SSO → select OpenID Connect and Sign in with Google.
Select Save.

No further configuration is required. Users authenticate with their Google account credentials.

Authorization Profiles

Authorization (Auth) Profiles define how the Platform authenticates with external web services. Configure profiles once and reuse them across API nodes, AI nodes, and other integrations. Key capabilities:

Define auth methods such as OAuth tokens, passwords, and custom parameters
Enforce consistent access control across multiple integrations
Test connections before putting them into production
Reuse profiles to reduce configuration effort

Access Authorization Profiles

Go to Autonomous Agents → Settings.
Select Security & Control → Authorization Profile.

Supported Auth Types

Type	Description	Use Case
OAuth V2	Token-based authorization supporting user-interactive flows	Third-party API access (for example “Sign in with Google”)
OAuth V2 Client Credential	Machine-to-machine flow using client ID and secret; no user interaction	Server-to-server communication, microservices

Add an Auth Profile

On the Authorization Profile page, select Create Authorization Profile (for your first profile) or Add New Auth.
In the New Authorization Mechanism dialog, select the Authorization Type.
Enter the Identity Provider Name (required).
Fill in the required fields (see Field Reference below).
Optionally select + Add Additional Field or + Add Authorization Field.
Configure Token Request Headers. For field descriptions, refer to the Token Request Headers.
Configure Mutual TLS (mTLS). For field descriptions, refer to the Mutual TLS Configuration.
Select Save New Auth.

Field Reference

Field	Description	Required	Auth Type
Authorization Type	OAuth V2 or OAuth V2 Client Credential	Yes	Both
Identity Provider Name	Name of the IDP, for example: Okta	Yes	Both
Description	Purpose of the auth profile	No	Both
Callback URL	Redirect URL after the user grants or denies permission	Yes	Both
Client ID	Unique app identifier used by the authorization server	Yes	Both
Client Secret	Confidential key for authenticating the app with the server	Yes	Both
Authorization URL	Endpoint where users authenticate and grant permissions	Yes	OAuth V2 only
Subdomain (Tenancy URL)	Tenant-specific URL in multi-tenant systems	Yes	OAuth V2 only
Token Request URL	Endpoint to exchange an auth code for an access token	Yes	Both
Scope	Level of access requested, for example: `read_profile`	No	Both
Refresh Token URL	Endpoint to get a new access token when the current one expires	No	OAuth V2 only
Auth Error Status Code	HTTP status code returned on authorization failure	No	Both
Additional Fields	Extra key-value pairs for the end user (for example: PIN code)	No	OAuth V2 only
Authorization Fields	Token-passing fields: Header, Payload, Query String, or Path Param	No	OAuth V2 only

If the Refresh Token URL or refresh token expires, the auth profile will fail wherever it is used. The admin receives an email notification to reconfigure.

Add Additional Fields

Use additional fields to collect supplemental authorization data from end users alongside standard credentials - for example, a PIN code or device ID.

Select + Add Additional Field in the New Authorization Mechanism window.
Enter a Field Key (name, for example: Pin code) and Field Value (for example: 2344567).
Select Done.

The field appears in the Additional Fields list where you can edit or delete it.

Add Authorization Fields

Authorization fields define how token data passes in API requests.

Parameter	Options	Required
Field Type	Header, Payload, Query String, Path Param	Yes
Field Key	Name of the auth field, for example: `Profile_id`	Yes
Field Value	Value for the field, for example: `123_xyz`	No

Select + Add Authorization Field in the New Authorization Mechanism window.
Fill in the fields and select Done.

Token Request Headers

Attach custom HTTP headers to every token endpoint request for this profile. Use this when your authorization server requires additional metadata - such as a tenant ID or correlation ID - alongside the standard OAuth parameters. Select + Add request header to add a row with a Field Name and Value. Up to 20 headers are defined per profile. Headers are sent in the order listed, after the platform’s standard headers (Content-Type, Authorization, etc.), which can’t be overridden. Values support {{context.*}} variable placeholders (for example, {{context.clientId}}) resolved at request time. Unresolved variables are replaced with an empty string and logged as a warning; the token request still proceeds.

Mutual TLS (mTLS)

mTLS allows the platform to present a client certificate during the TLS handshake when connecting to enterprise systems that require it. The certificate can be presented at the token endpoint, for downstream API requests, or both. When mTLS is enabled, configure the following fields. Apply mTLS To - Choose where the client certificate is presented:

Option	Behavior
Token Endpoint & API Requests (default)	Presented at both the token endpoint and outbound API node calls.
Token Endpoint Only	Presented only when acquiring tokens.
API Requests Only	Presented only on outbound API node calls.

Client Certificate (PEM) - Upload your client certificate file (.pem, .crt, .cer). If the file includes the full chain (leaf, intermediates, and root), no separate CA certificate is needed. After upload, the platform displays the Subject CN, Issuer CN, validity dates, and a status badge - OK, Expiring Soon (≤ 30 days), or Expired - for each certificate in the file.
Client Private Key (PEM) - Upload the private key corresponding to the client certificate (.pem, .key). The platform validates that the key matches the leaf certificate’s public key.
Private Key Passphrase - Required only if the private key is encrypted.
CA Certificate / Chain (PEM) - Required only if your certificate chain is in a separate file from the client certificate (.pem, .crt, .cer).
Certificate Alias - Enter the name (up to 100 characters) to identify this certificate. Doesn’t affect authentication behavior.

Test an Auth Profile

Select Test next to a configured profile to verify it establishes a connection with the external service. If the test fails, edit the profile with the correct values and retest.

Manage Auth Profiles

Edit: Select the ellipsis (⋯) menu → Edit → update fields in the Update Authorization Mechanism window → select Update New Auth.

Authorization Type and Name cannot be changed after the profile is created. All other fields are editable.

Delete: Select the ellipsis (⋯) menu → Delete → confirm. Deleted profiles can’t be recovered.

Encryption Key Management

The Platform encrypts all account data. You can use the Platform’s built-in key management or integrate with your organization’s external Key Management System (KMS) using Bring Your Own Key (BYOK).

Encryption is configured at the account level. All apps within an account share the same encryption key.

Platform-Managed Encryption

The Platform automatically encrypts all data using built-in keys - no configuration required. Keys rotate every 90 days.

Bring Your Own Key (BYOK)

Use keys stored in your own KMS to control encryption and decryption. The Platform communicates with your external KMS for all cryptographic operations. If your KMS is unavailable, the Platform falls back to default encryption. Supported providers: AWS KMS, Azure Key Vault

Configure BYOK

Go to Settings → Key Management.
Select Configure BYOK.
Select your cloud provider and enter the required configuration details.

Azure Key Vault

Required service principal permissions:

Key Vault Crypto Service Encryption User
Microsoft.KeyVault/vaults/keys/encrypt/action
Microsoft.KeyVault/vaults/keys/decrypt/action
Microsoft.KeyVault/vaults/keys/wrap/action
Microsoft.KeyVault/vaults/keys/unwrap/action
Microsoft.KeyVault/vaults/keys/read

Configuration fields:

Field	Description
Key Vault URL	Endpoint of your Azure Key Vault instance
Tenant ID	Microsoft Entra ID tenant identifier for the Azure subscription where the Key Vault resides
Key Nickname	User-defined label to identify the key in the Platform
Activation Date	Date from which the key becomes active and available for use

AWS KMS

Required IAM permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:DescribeKey",
        "kms:GenerateDataKey"
      ],
      "Resource": "arn:aws:kms:*:*:key/*",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:tenant_id": "${aws:RequestedRegion}"
        }
      }
    }
  ]
}

Configuration fields:

Field	Description
ARN	Amazon Resource Name that uniquely identifies your AWS KMS key
Role ARN	ARN of the IAM role that grants the Platform permission to use the KMS key
Key Nickname	User-friendly label to identify the key in the Platform
Activation Date	Date from which the key can be used for encryption and decryption

API Scopes

API Scopes replace unrestricted management API keys with permission-limited, scoped keys. Create API apps with specific scopes so each integration only accesses the endpoints it needs. Key rules:

API keys are restricted to assigned scopes; requests to other scopes are automatically rejected.
Multiple API keys can exist per app.
An API key can’t be shared across multiple apps.
API keys can’t be modified after creation - only deleted.
Each key can only be copied once (copy-once policy).

Access API Scopes

Go to Autonomous Agents → Settings.
Select Security & Control → API Scopes.

Supported Scopes

Scope	Description
Deploy Tool	Deploy a specific tool into an environment (sync or async)
Undeploy Tool	Remove a deployed tool from an environment
Deploy Model	Deploy an open-source or fine-tuned model in Ready to Deploy state
Undeploy Model	Remove a deployed model from an environment
Import Model	Import a model into the Platform in chunks
Import Tool	Import a new tool into the system
Export Model	Export a trained AI model from the system
Export Tool	Export a tool’s configuration and associated data
Deploy Guardrails	Deploy guardrails for security and content moderation
Undeploy Guardrails	Remove previously deployed guardrails
View Connections	View connection details
Manage Connections	Create and update connections

Create an API App

On the API Scopes page, select Create an API App.
Select Untitled App and enter an app name.
Select the required scopes from the list.
Select Next.

Create an API Key

This step completes the app setup. At least one API key is required.

Select Create API Key.
Enter a key name and select Generate Key.
Select Copy and Close to copy the key.

The API key is shown only once. Save it in a secure location. If lost, you must revoke it and generate a new one - this may disrupt any services currently using the key.

Select Done.

The app summary displays: app name, assigned scopes, creator, and creation date.

Manage Apps and Keys

Rename or update scopes: Hover over the app → select Edit → update the name or select/deselect scopes → select Save. Delete an API key: In the app’s API Keys tab, hover over the key → select Delete → confirm.

Deleting a key that is actively in use will immediately break any services relying on it. Generate a replacement key before deleting if the key is in production use.

Delete an app: Hover over the app → select Delete → confirm. For role and permission details for API-scoped apps, see Role Management.

Custom Scripts

Admins can import, deploy, and manage custom scripts directly from Settings → Manage Custom Scripts. Scripts run in isolated containers and can be invoked via the API node endpoint or embedded in the Function node of a tool flow.

Capability	Description
Task Automation	Automate repetitive or complex tasks without manual intervention
Secure API Integration	Call scripts via API endpoints with key-based authentication
Customization	Implement business-specific logic and custom workflows
Data Processing	Transform, filter, or validate data for operational requirements
Error Handling	Define custom error-checking and fallback mechanisms

Access Custom Scripts

Go to Autonomous Agents → Settings.
Select Manage Custom Scripts in the left menu.

Import and Deploy a Script

Select + Import or + Import New, then complete the four-step wizard.

Step 1: General Details

Field	Details
Script Name	A unique name for the script
Description	Purpose and capabilities of the script
Base Language	JavaScript (v20.19.0) or Python (v3.10.15)
Project File	`.zip`, `.gz`, or `.tar` file - max 1 GB

Select Validate after uploading. Resolve any errors before proceeding. Project structure requirements:

Include main.py (Python) or main.js (JavaScript) at the archive root - only functions defined in this file are exposed via API.
Include requirements.txt (Python) or package.json (JavaScript) at the root if your script has external dependencies.
Use relative imports when referencing files within the project.
Access environment variables using os.getenv('<key>') in Python or process.env.<key> in JavaScript.

Download the sample project from the wizard to verify your file matches the required structure. Structure differs by language, so use the correct sample for your chosen language.

Step 2: Runtime Settings

Setting	Description	Range / Default
Environment Variables	Key-value pairs accessible from the script at runtime	Custom
Execution Timeout	Maximum time the script is allowed to run	30–600 seconds

Built-in environment variables (always available):

UPLOADS_DIR - Read-only access to files uploaded via Public APIs.
WORKSPACE_DIR - Read-write directory for the script’s file operations.

Both directories are only accessible while the container is deployed.

Step 3: Resource Allocation

Scaling parameters:

Parameter	Range	Default
Min Replicas	1–10	1
Max Replicas	1–10	1
Average Compute Utilization	1–100%	75%

Average Compute Utilization is disabled when Min and Max replicas are equal. Hardware profiles:

Profile	Actual CPU & Memory	Credits/Hour
1 vCPU / 2 GB	0.7 vCPU / 1.1 GB	0.077
2 vCPUs / 4 GB	1.5 vCPUs / 2.5 GB	0.154
2 vCPUs / 8 GB	1.5 vCPUs / 6.5 GB	0.144
4 vCPUs / 8 GB	3.5 vCPUs / 6 GB	0.308
4 vCPUs / 16 GB	3.5 vCPUs / 13.5 GB	0.288

Step 4: Review and Deploy

Review all sections - General Details, Runtime Settings, and Resource Allocation. Select any section to go back and edit.
Accept the Terms and Conditions.
Optionally select Save as Draft to deploy later.
Select Deploy.

After successful deployment, a confirmation email is sent to the admin with the subject “Custom script deployed successfully - API Endpoint Available,” including remaining credits and total allocation.

Script Statuses

Status	Description	Can Redeploy?
Draft	Saved but not yet deployed	No
Deploying	Deployment in progress	No
Ready to Deploy	Configured and ready for deployment	Yes
Deployed	Running successfully in the environment	Yes
Deployment Failed	Deployment didn’t complete successfully	Yes

Hover over a Deployment Failed status to see the error reason.

Actions

Action	Available When	Description
Export	All statuses	Downloads the project as a `.zip` file to your local system
Undeploy	Deployed	Removes the script from all deployed locations; status changes to Ready to Deploy
Delete	Not deployed	Permanently removes the script and all its data - can’t be undone
Redeploy	Deployed, Ready to Deploy	Re-runs the import flow so you can update description, project file, runtime settings, or resource allocation (name, language, and version can’t be changed)

You cannot delete a deployed script. Undeploy it first, then delete.

After a script is undeployed, a confirmation email is sent to the admin with the subject “Your custom script has been undeployed successfully.”

Script Detail Pages

Each script entry has four tabs:

Tab	What It Shows
Overview	Current configuration (General Details, Runtime Settings, Resource Allocation) and available actions based on deployment status
Deployment History	Full history of deployments and undeployments - version, timestamp, duration, deployed by, and final status. Expand any row for detailed configuration at that point in time
Endpoint	The activated endpoint in cURL, JavaScript, and Python formats. Copy any format directly into your application. Only available when the script is in Deployed status
API Keys	Create and manage secret API keys for authenticated access to the script’s endpoint

API Keys for Scripts

Go to the script’s API Keys tab.
Select Create a New API Key.
Enter a name and select Generate Key.
Select Copy and Close.

Secret keys are shown only once. Store the key securely. If lost, delete the key and generate a new one.

To delete a key: hover over it → select the Delete icon → confirm. A deleted key is immediately invalidated.

Use a Script via the API Node

In the API node configuration, select Define Request.
On the script’s Endpoint tab, copy the cURL code.
Paste it into the Edit Request dialog.
Select an Auth Profile if the endpoint requires authentication (or select None).
Add headers (for example: Content-Type: application/json) and body parameters as needed.
Select Test to validate the request, then Save.

For full API node configuration options, see API Node.

​Authentication Settings

​How SSO and MFA Work Together

​Access Authentication Settings

​Single Sign-On (SSO)

​How SSO Works

​SSO Status

​Enable SSO

​Disable SSO

​SSO-Excluded Users

​Add an Excluded User

​Configuration Parameters

​Multi-Factor Authentication (MFA)

​Enable MFA

​Disable MFA

​MFA for Users (First Login)

​SSO Protocol Reference

​SAML 2.0

​How SAML works

​Okta

​OneLogin

​Other SAML Providers

​WS-Federation

​Windows Azure

​Other WS-Federation Providers

​OpenID Connect

​Google

​Authorization Profiles

​Access Authorization Profiles

​Supported Auth Types

​Add an Auth Profile

​Field Reference

​Add Additional Fields

​Add Authorization Fields

​Token Request Headers

​Mutual TLS (mTLS)

​Test an Auth Profile

​Manage Auth Profiles

​Encryption Key Management

​Platform-Managed Encryption

​Bring Your Own Key (BYOK)

​Configure BYOK

​Azure Key Vault

​AWS KMS

​API Scopes

​Access API Scopes

​Supported Scopes

​Create an API App

​Create an API Key

​Manage Apps and Keys

​Custom Scripts

​Access Custom Scripts

​Import and Deploy a Script

​Step 1: General Details

​Step 2: Runtime Settings

​Step 3: Resource Allocation

​Step 4: Review and Deploy

​Script Statuses

​Actions

​Script Detail Pages

​API Keys for Scripts

​Use a Script via the API Node

Authentication Settings

How SSO and MFA Work Together

Access Authentication Settings

Single Sign-On (SSO)

How SSO Works

SSO Status

Enable SSO

Disable SSO

SSO-Excluded Users

Add an Excluded User

Configuration Parameters

Multi-Factor Authentication (MFA)

Enable MFA

Disable MFA

MFA for Users (First Login)

SSO Protocol Reference

SAML 2.0

How SAML works

Okta

OneLogin

Other SAML Providers

WS-Federation

Windows Azure

Other WS-Federation Providers

OpenID Connect

Google

Authorization Profiles

Access Authorization Profiles

Supported Auth Types

Add an Auth Profile

Field Reference

Add Additional Fields

Add Authorization Fields

Token Request Headers

Mutual TLS (mTLS)

Test an Auth Profile

Manage Auth Profiles

Encryption Key Management

Platform-Managed Encryption

Bring Your Own Key (BYOK)

Configure BYOK

Azure Key Vault

AWS KMS

API Scopes

Access API Scopes

Supported Scopes

Create an API App

Create an API Key

Manage Apps and Keys

Custom Scripts

Access Custom Scripts

Import and Deploy a Script

Step 1: General Details

Step 2: Runtime Settings

Step 3: Resource Allocation

Step 4: Review and Deploy

Script Statuses

Actions

Script Detail Pages

API Keys for Scripts

Use a Script via the API Node