Observability Integrations

Observability tools provide real-time system insights, metric analysis, and automated troubleshooting capabilities.

Integrated observability tools can be used by an agent team with the Observability Agent skill.

Multi-integration configuration

You can configure multiple instances of the same type of observability integration.

To add an additional integration, click + Add Instance on the integration configuration page.

The following observability integrations are available:

AppDynamics

The Biggy AppDynamics integration is used for full-stack/APM monitoring.

To configure the Biggy AppDynamics integration, populate the following fields:

Field	Description
AppD Controller URL	Enter the controller URL for your AppDynamics instance. (For example, `https://xyz.saas.appdynamics.com`)
Client ID	Your AppDynamics Client ID is a combination of the client name and account name in this format: `[CLIENT_NAME]@[ACCT_NAME]`
Client Secret	Auto-generated AppDynamics client secret.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
Deployment Type	Select whether your AppDynamics integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
Agent Notes	Add notes to help Biggy understand your AppDynamics environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

AWS CloudWatch Logs

The Biggy AWS CloudWatch Logs integration lets Biggy discover log groups and run CloudWatch Logs insights queries in your AWS account.

AWS CloudWatch Logs credentials are account-scoped, so add one instance per AWS account you want Biggy to search. We recommend connecting through an IAM role with short-lived credentials, so there is nothing to store or rotate. Access keys remain available as a legacy option.

The integration is read-only. Biggy cannot create, modify, or delete anything in your AWS account.

Query-based access

Biggy reads your logs only on demand with CloudWatch Logs Insights queries and bounded event reads. Nothing is streamed, exported, or stored in Biggy, and subscription filters or Firehose deliveries are never created. Every query scans data in your account, so Biggy narrows by log group and time window before it reads anything.

Required permissions

Grant the IAM role the following read-only CloudWatch Logs actions:

logs:DescribeLogGroups
logs:StartQuery
logs:GetQueryResults
logs:StopQuery
logs:FilterLogEvents

Grant logs:DescribeLogGroups and logs:StopQuery on "Resource": "*". AWS does not support resource-level permissions for either action, so an ARN-scoped grant denies them and Biggy can neither list log groups nor stop a long-running query. You can narrow logs:StartQuery, logs:GetQueryResults, and logs:FilterLogEvents to specific log group ARNs if you prefer IAM to bound what Biggy can search.

Configure the AWS CloudWatch Logs integration

To configure the integration with the recommended IAM Role method:

In the AWS Cloudwatch Logs web app integration page, go to the Connections section and copy the External ID.
In the AWS account you want to connect, open IAM > Roles > Create role and choose Custom trust policy. The trust policy names the Biggy AWS account as the trusted principal, pins the exact Biggy role that may assume yours, and requires the External ID.
IAM Role method
The IAM Role method is available only when your Biggy deployment publishes an AWS principal for your account to trust. If the method is unavailable on your deployment, use the Access Keys method, or contact BigPanda support.
Attach an inline policy to the role that grants the five read-only CloudWatch Logs actions Biggy calls. This policy cannot write, delete, or reconfigure anything in your account:
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BiggyCloudWatchLogsRead",
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogGroups",
        "logs:StartQuery",
        "logs:GetQueryResults",
        "logs:StopQuery",
        "logs:FilterLogEvents"
      ],
      "Resource": "*"
    }
  ]
```
Narrowing the scope
You can narrow logs:StartQuery, logs:GetQueryResults, and logs:FilterLogEvents to specific log group ARNs if you prefer IAM to bound what Biggy can search.
Keep logs:DescribeLogGroups and logs:StopQuery on "Resource": "*" in a second statement. AWS does not support resource-level permissions for either action, so an ARN-scoped grant denies them, and Biggy can neither list groups nor stop a long-running query. The optional log group prefix allowlist is a Biggy-side convenience on top of IAM, never a substitute for it.

The following fields in the web app must be populated regardless of the selected authentication method:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production AWS CloudWatch Logs`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your CloudWatch Logs environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which AWS account this is, which log groups belong to which applications, naming conventions, and which fields your logs use for request IDs or error codes.
Authentication Method	Select how Biggy authenticates with AWS. IAM Role (recommended) - Biggy assumes a role in your account through AWS STS, using its published principal and the External ID generated for this instance. Credentials are short-lived and refreshed automatically, with nothing long-lived to rotate. Access Keys - a legacy option that authenticates with the access keys of a read-only IAM user.
Role ARN	This option only appears if you selected IAM Role as the authentication method. The ARN of the IAM role in your account whose trust policy names the Biggy principal and the External ID. (For example, `arn:aws:iam::<your_account_id>:role/BiggyCloudWatchLogs`) Required for the IAM Role method.
External ID	This option only appears if you selected IAM Role as the authentication method. Auto-generated by Biggy for this instance. Add it to the role trust policy's `sts:ExternalId` condition. Click Regenerate to issue a new External ID. If you do, update the trust policy to match.
Access Key ID	This option only appears if you selected Access Keys as the authentication method. Enter the access key ID of the read-only AWS IAM user account.
Secret Access Key	This option only appears if you selected Access Keys as the authentication method. Enter the secret access key of the read-only AWS IAM user account.
Default AWS Region	The region Biggy queries when a question does not name one, and the region Verify Connection probes. GovCloud regions are not available with the IAM Role method yet.
Connectivity	After entering the authentication details and default region, click Verify Connection to confirm that the connection to AWS CloudWatch Logs is established.
Additional regions (Optional)	Regions Biggy may also query when a question or a discovered log group ARN points there. The default region is always included.
Log group prefix allowlist (Optional)	Enter one log group prefix per line. When set, Biggy only lists and queries log groups whose names start with one of these prefixes. Leave empty to let the IAM policy alone decide what Biggy can see. (For example, `/aws/lambda/`)

AWS Health

The Biggy AWS Health integration monitors AWS events that affect your account. This includes service issues, scheduled changes, and account notifications, and the specific resources each event affects. The integration is read-only, so Biggy cannot create, modify, or acknowledge anything in your AWS account.

The AWS Health API is account-scoped, so add one instance per AWS account you want Biggy to monitor. Each instance connects with the access keys of a read-only IAM user created in that account.

A support plan with Health API access is required

The Health API is the account-specific event feed behind the AWS Health Dashboard, and is only available for accounts on a support plan that includes it.

Required permissions

Required permissions

Grant the read-only IAM user the following AWS Health actions:

health:DescribeEvents
health:DescribeEventDetails
health:DescribeAffectedEntities
health:DescribeEventTypes

Grant all four actions on "Resource": "*". AWS does not support resource-level permissions for the Health API.

Configure the AWS Health integration

To configure the AWS Health integration:

In the AWS account you want to connect, open IAM > Users > Create user. Grant programmatic access only, and leave console access switched off.
Attach an inline policy to the user that grants the four read-only Health actions Biggy calls. This policy cannot write, mutate, or acknowledge anything in the account:
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BiggyAwsHealthRead",
      "Effect": "Allow",
      "Action": [
        "health:DescribeEvents",
        "health:DescribeEventDetails",
        "health:DescribeAffectedEntities",
        "health:DescribeEventTypes"
      ],
      "Resource": "*"
    }
  ]
}
```
Why the resource is *
AWS does not support resource-level permissions for the Health API. The health:Describe* actions accept only "Resource": "*". Narrowing the policy to specific ARNs makes every call fail rather than scoping it. With the * permission applied, the actions are still read-only, and the account boundary is the scope.
On the user's Security credentials tab, create an access key for a third-party service. AWS displays the secret access key only once, so copy both the Access Key ID and the secret access key before you leave the page.
In the web app AWS Health integration page, populate the fields described below, then click Verify Connection to test the connection.

Rotating keys

Access keys do not rotate on their own. When you rotate them in AWS, edit this instance with the new pair and click Verify Connection again. Biggy holds no cached copy of the old credentials, so reads start failing as soon as you deactivate the old key.

Populate the following fields in the web app to set up the integration:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `US East Production`)
Access Key ID	The Access Key ID of the read-only IAM user you created for Biggy.
Secret Access Key	The secret access key that pairs with the Access Key ID. Biggy encrypts both values at rest and masks them in the form. An administrator editing the instance can reveal them.
Connectivity	After entering the Access Key ID and Secret Access Key, click Verify Connection to confirm that the connection to AWS Health is established.
Routing Instructions	Describe when this AWS Health instance should be used. (For example, `This is the US East production account. Use for any queries about US-based production services.`) Routing instructions are only necessary when multiple instances of AWS Health are configured.
AWS Health Agent Notes	Add notes to help Biggy understand your AWS Health environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, if your alerts contain a specific field that is used to identify the type of application or service, provide that information here. Click Generate with AI to draft these notes automatically.

Azure Data Explorer

The Biggy Azure Data Explorer integration lets Biggy run read-only Kusto Query Language (KQL) queries on your databases.

Biggy connects to your Azure Data Explorer (ADX) cluster using a Microsoft Entra app registration and queries only the databases you list. Queries against any other database are rejected before they reach the cluster.

The integration is read-only. Biggy cannot create, modify, or delete anything in your cluster. The app is granted only the Database Viewer role, which permits table reads and .show tables / .show table schema. Management and write commands are blocked before they reach the cluster, and every query carries a server-side timeout and row cap.

Required permissions

The Microsoft Entra app registration needs a Directory (tenant) ID, an Application (client) ID, and a client secret. No Microsoft Graph API permissions or admin consent are required.

In Azure Data Explorer, grant the app the Database Viewer role on each database you want Biggy to query. This role grants table reads and the .show tables and .show table schema commands. No Admin, Ingestor, or User role is required.

Configure the Azure Data Explorer integration

To configure the integration:

In Microsoft Entra ID, go to App registrations and select New registration to register an app for Biggy.
Copy the Directory (tenant) ID and Application (client) ID, then create a client secret under Certificates & secrets and copy its value.
In the Azure Data Explorer query editor, grant the app the Viewer role on each database Biggy should query:
```
.add database ['<database>'] viewers ('aadapp=<client-id>;<tenant-id>')
```
Run this command for every database Biggy should query.
Copy the cluster URI from the cluster overview page (for example, https://<cluster>.<region>.kusto.windows.net).
Populate the following fields in the web app to set up the integration:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Azure Data Explorer`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and become required once a second instance exists.
Agent Notes (Optional)	Add schema nuances or tips so Biggy can better interact with your Azure Data Explorer instance. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note timestamp columns, naming conventions, and which services map to which tables.
Cluster URL	The cluster query URI from the Azure Data Explorer cluster overview page. (For example, `https://<cluster>.<region>.kusto.windows.net`)
Azure Cloud	Selects the Microsoft Entra sign-in authority and which cluster hostnames are accepted. Choose Azure (public cloud), or the matching cloud if the cluster is in US Government or China.
Microsoft Entra Tenant ID	The Directory (tenant) ID of the Microsoft Entra tenant that owns the app registration.
Application (client) ID	The Application (client) ID of the app registration you created for Biggy.
Client Secret	The client secret created for the app registration. Biggy encrypts this value at rest and masks it in the form.
Allowed Databases	Enter one database per line, or comma-separated. Biggy can only query the databases listed here. Queries against any other database are rejected before they reach the cluster.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the Azure Data Explorer instance is only reachable from inside your network, such as a cluster reachable only over Private Link. Requests then route through a relay client assigned on the Relay Clients page.
Connectivity	After entering the connection details, click Verify Connection to confirm that the connection to Azure Data Explorer is established.

Azure Monitor

The Biggy Azure Monitor integration gives Biggy read-only access to log analytics, including Kusto Query Language (KQL) queries, metrics, resource health, and service health.

Azure Monitor is connected per Azure subscription. Each instance signs in as a Microsoft Entra app registration and is scoped to exactly one subscription, so add one instance per subscription you want Biggy to see.

Everything Biggy calls is read-only. Biggy cannot create, modify, restart, or delete anything in your subscription.

Required permissions

Grant the Microsoft Entra app registration the following built-in read-only roles:

Reader on the subscription: resource list, subscription probe, resource health, and service health.
Monitoring Reader on the subscription: metric definitions and metric data.
Log Analytics Reader on each listed log analytics workspace: KQL queries, including workspace-based application Insights tables.

All three are built-in read-only roles. None of them can change, restart, or delete a resource.

Configure the Azure Monitor integration

To configure the integration:

Register an app for Biggy. In Microsoft Entra ID > App registrations > New registration, create a single-tenant app. No redirect URI is needed. Copy the Directory (tenant) ID and Application (client) ID from the app's Overview page.
Create a client secret. Under Certificates & secrets, select New client secret, pick an expiry that your rotation policy allows, and copy the secret Value immediately, because Azure shows it only once. Note the expiry date: when the secret lapses, Verify Connection reports a credential failure until you paste a new secret.

Assign read-only roles on the subscription. Open the subscription's Access control (IAM) page and select Add role assignment to grant the app the Reader and Monitoring Reader roles. Both are built-in read-only roles, so nothing here can change, restart, or delete a resource. You can also assign the roles with the Azure CLI:

# Sign in, then assign the two subscription roles to the app registration
az login
APP_ID=<application-client-id>
SUBSCRIPTION_ID=<subscription-id>
az role assignment create --assignee "$APP_ID" --role "Reader" --scope "/subscriptions/$SUBSCRIPTION_ID"
az role assignment create --assignee "$APP_ID" --role "Monitoring Reader" --scope "/subscriptions/$SUBSCRIPTION_ID"

# Optional: for each Log Analytics workspace Biggy should query
WORKSPACE_RESOURCE_ID=<workspace-resource-id>
az role assignment create --assignee "$APP_ID" --role "Log Analytics Reader" --scope "$WORKSPACE_RESOURCE_ID"

(Optional) You can choose to allow log analytics workspaces. For each workspace Biggy can query, grant the app the Log Analytics Reader role on the workspace and on the workspace Overview page, copy its Workspace ID, GUID. Workspace-based Application Insights resources write into a workspace, so their App* tables are covered by the same role. Leave the list empty to connect metrics and health only.
Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Azure Monitor`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended and are required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Azure Monitor environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which resource groups or workspaces back which applications, and any custom log conventions.
Microsoft Entra Tenant ID	The Directory (tenant) ID of the Microsoft Entra tenant that owns the app registration.
Application (client) ID	The Application (client) ID of the app registration. This GUID is on the app registration's Overview page.
Subscription ID	The ID of the Azure subscription this instance is scoped to.
Client Secret	The client secret value created for the app registration. Biggy encrypts this value at rest and masks it in the form.
Azure Cloud	Selects the Microsoft Entra, Azure Resource Manager, and Log Analytics endpoints. Leave on Azure (public) unless the subscription lives in a sovereign cloud, such as Azure Government or Azure China.
Log Analytics Workspace IDs (Optional)	Enter one Workspace ID GUID per line, taken from each workspace's Overview page rather than the workspace name. Only listed workspaces can be queried, and the app needs the Log Analytics Reader role on each. Leave empty to enable metrics and health only.
On-premises instance	Enable this toggle when the Azure Monitor instance is only reachable from inside your network, such as a Log Analytics workspace reachable only over Private Link. Requests then route through a relay client assigned on the Relay Clients page. Public Azure endpoints need no relay.
Connectivity	After entering the connection details, click Verify Connection to confirm that the connection to Azure Monitor is established.

Broadcom DX Spectrum

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Broadcom DX Spectrum integration gives Biggy access to network alarms, devices, topology, landscapes, and root cause and impact from Broadcom DX Spectrum.

Biggy connects to the DX Spectrum OneClick web services API with a dedicated OneClick user that has read access to the landscapes Biggy should see. Each instance connects to one OneClick server and reads every landscape its user can see. To connect another Spectrum deployment, add another instance.

The integration is read-only. Biggy never acknowledges or clears alarms and never creates events, so the OneClick user does not need any alarm-management, model-management, or event-creation privileges.

DX NetOps Performance Management not included

DX NetOps Performance Management metrics are not part of this integration, so Biggy does not read them.

Requirements

To use the integration, you need:

DX Spectrum 10.4 or later (DX NetOps) with the OneClick web services API enabled. The web services API is enabled on the OneClick server by default.
A dedicated OneClick user with the Operator license and read access to the landscapes Biggy should see. No other privileges are needed.
If the OneClick server certificate was not issued by a public certificate authority, the private CA certificate chain in PEM format.
If the OneClick server is not reachable from the internet, a relay client assigned on the Relay Clients page.

Configure the Broadcom DX Spectrum integration

To configure the integration:

In OneClick, open the Users tab and create a dedicated user for Biggy. (For example, biggy-readonly) Assign the user the Operator license and read access to the landscapes Biggy should see. Do not grant alarm-management, model-management, or event-creation privileges.
Copy the OneClick web server address. (For example, https://oneclick.example.com:8443)
In the web app, go to Integrations > Manage Integrations > Broadcom DX Spectrum and click + New instance.

Populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Broadcom DX Spectrum`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Broadcom DX Spectrum environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which landscapes or global collections map to which sites, naming conventions, and the devices that matter most during an incident. This information helps Biggy pick the right models.
OneClick URL	Enter the OneClick web server address copied in step 2. (For example, `https://oneclick.example.com:8443`) Biggy calls the web services API under `/spectrum/restful`. Pasting a URL that includes the `/spectrum/restful` path, or a OneClick console URL, also works. Plain `http://` addresses are accepted only on an on-premises instance.
Username	The dedicated read-only OneClick user you created for Biggy in step 1. (For example, `biggy-readonly`)
Password	The password for the OneClick user. Biggy encrypts this value at rest and masks it in the form.
Custom CA Certificate (PEM) (Optional)	If the OneClick server certificate was not issued by a public certificate authority, paste the CA certificate chain (PEM) so Biggy can verify the server TLS certificate.
On-premises instance	Enable this toggle when the Broadcom DX Spectrum instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Broadcom DX Spectrum is established. Biggy logs in with the OneClick user credentials and reads the landscapes. The result shows how many landscapes the user can see.
Click Create Instance.

Troubleshoot the connection

If verification fails, the type of failure points to the cause:

Rejected login: The username or password is wrong.
Refused read: The OneClick user has no landscape access.

Catchpoint

The Biggy Catchpoint integration provides Biggy with read-only access to Catchpoint synthetic tests, alerts, service-level objectives (SLOs), nodes, Real User Monitoring (RUM) data, and Internet Sonar outages.

Biggy connects to the Catchpoint REST API v3 at https://io.catchpoint.com/api/v3 and authenticates with a REST API key. Biggy always calls this address so there is no URL to enter.

The integration is read-only. Biggy never creates, changes, or pauses tests, alerts, or nodes.

Use a dedicated API key

The Catchpoint REST API v3 limits analytics calls per key, and the limits are shared by everything that uses the same key. We recommend creating a key dedicated to Biggy. To stay within the limits, Biggy keeps short default query windows and caps every window at 7 days.

Required permissions

A Catchpoint REST API key has the permissions of the contact it is bound to. Catchpoint does not offer a separate read-only scope, so bind the consumer to a contact that can only view tests, alerts, and dashboards.

Biggy reads the following Catchpoint data:

Tests and test results
Alerts
SLOs
Nodes
Real User Monitoring (requires a Catchpoint RUM license)

Real user monitoring is optional

RUM applications and data require a Catchpoint RUM license. Without one, other data points are still received, but the RUM tools report that the account has no license.

Configure the Catchpoint integration

To configure the integration:

In Catchpoint, go to Settings > Integrations > REST API and click Add Consumer.
Bind the consumer to a contact that can only view tests, alerts, and dashboards. See Required permissions for more information.
Copy the consumer's REST API key. You will need it during configuration.
If the consumer has an Allowed IPs list, add the Biggy egress IP addresses to it.
If you prefer that the calls leave from your own network, enable On-premises instance in step 6 and assign a Biggy relay client. Then add the relay client's address to the Allowed IPs list instead.
In Biggy, go to Integrations > Manage Integrations > Catchpoint and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Catchpoint`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Catchpoint environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which tests, products, and folders matter to which team, and whether the account has a RUM license.
REST API key	The Catchpoint REST API key copied in step 3. Biggy encrypts this value at rest and masks it in the form.
On-premises instance	Enable this toggle when the Catchpoint instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page. If the consumer has an Allowed IPs list, add the relay client's address to it.

In the Connectivity section, click Verify Connection to confirm that the connection to Catchpoint is established. Biggy reads the identity behind the key and shows the contact email associated with it.
Click Create Instance.

Key expiration

Catchpoint REST API keys expire after 2 years by default. Before the key expires, create a new key in Catchpoint, edit this instance with the new key, and click Verify Connection again.

Centreon

The Biggy Centreon integration gives Biggy host and service status, timelines, metrics, downtimes, and acknowledgements from Centreon.

Biggy connects to Centreon's centreon-mcp Model Context Protocol (MCP) server over Streamable HTTP, and authenticates with a Centreon API token sent in the centreon-api-token request header. You host and run the centreon-mcp server in your own environment, and the server calls your Centreon central server on behalf of Biggy.

Biggy calls only the tools you allow on the server. Reads run automatically, and acknowledgements, downtimes, checks, and configuration changes wait for approval.

Requirements

To use the integration, you need:

Centreon's centreon-mcp server, running in your environment.
An HTTPS endpoint for the server at the /mcp path, or a relay client assigned on the Relay Clients page. Local stdio and npx launches are not supported.
A Centreon API token for a dedicated user whose access control lists (ACLs) only allow what Biggy should read. Biggy acts with the permissions of the Centreon user who owns the API token. Create a dedicated user for Biggy, and limit the user's ACLs to the hosts, services, and actions Biggy should see.

Plain HTTP by default

The centreon-mcp server listens on port 8000 at /mcp over plain HTTP. Put the server behind an HTTPS proxy, or enable On-premises instance and route requests through a relay client.

Configure the Centreon integration

To configure the integration:

Start the centreon-mcp server with one of the following commands:
```
uv run centreon-mcp-server
```
```
docker compose up
```
Set the following environment variables on the server:
- CENTREON_BASE_URL: The URL of your Centreon central server.
- CENTREON_MCP_HOST: Set to 0.0.0.0 so the server accepts connections from outside the host.
Expose the server over HTTPS at the /mcp path, and copy the full server URL. (For example, https://centreon.example.com:8000/mcp) If the server is only reachable on your network, use a relay client instead.
In Centreon, go to Administration > Authentication Tokens. Add a token of type API for the dedicated user you created for Biggy, and copy the token value.
In the web app, go to Integrations > Manage Integrations > Centreon and click + New instance.

Populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Centreon`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Centreon environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which Centreon projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Authentication Method	Select how Biggy authenticates with the centreon-mcp server: API Key Header: Biggy sends the API key in a request header that you name, for MCP servers that expect an API key instead of a bearer token. No Authentication: No credentials are sent. Typically only used for MCP servers running inside your network and reached via a relay client.
Centreon MCP Server URL	The Streamable HTTP endpoint of your centreon-mcp server, copied in step 2. (For example, `https://centreon.example.com:8000/mcp`) Local `stdio` and `npx` launches are not supported.
API Key	The Centreon API token copied in step 3. Biggy encrypts this value at rest and masks it in the form.
API Key Header Name	The name of the request header that carries the API key. Keep the default value, `centreon-api-token`, which is the header the centreon-mcp server reads the token from.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the Centreon instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Centreon is established. Verify Connection counts hosts by status to test the connection.
Click Create Instance.
In the Allowed tools and approvals section, review the tools Biggy loaded from the centreon-mcp server. Biggy pre-selects the read-only tools and gates writes and executions behind approval. Biggy calls no tool on this server until at least one tool is allowed.
Reads on the selected tools run automatically. Acknowledgements, downtimes, checks, and configuration changes wait for approval.

Checkly

The Biggy Checkly integration gives Biggy access to check status, latency, failures, and root-cause analysis from Checkly synthetic and API checks.

Biggy connects to the Checkly-hosted Model Context Protocol (MCP) server at https://api.checklyhq.com/mcp and authenticates with a Checkly API key, which Biggy sends as a bearer token.

The API key's role decides what Biggy can do in your Checkly account. A Checkly API key receives every Checkly MCP permission except inviting members, so the key's role is what keeps Biggy read-only. Create the key with the Read Only role.

Configure the Checkly integration

To configure the integration:

In Checkly, create a read-only API key:
- On Starter, Team, and Enterprise plans, open Account Settings and select API keys. Click Create service API key and set the role to Read Only.
- On other plans, open User Settings >API keys, then create a user API key (cu_).
Copy the key. You will need it during configuration.
If you created a user API key that has access to more than one Checkly account, open Account Settings > General. Copy the account ID of the account Biggy should read.
In the web app, go to Integrations > Manage Integrations > Checkly and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Checkly`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent notes (Optional)	Add notes to help Biggy understand your Checkly environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which Checkly projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Checkly MCP Server URL	The address of the Checkly-hosted MCP server, `https://api.checklyhq.com/mcp`. Checkly sets this value, and you cannot change it.
Bearer Token	The read-only Checkly API key you created in step 1. Biggy sends it as a bearer token to the Checkly MCP server.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. If your user API key has access to more than one Checkly account, add a header with the name `X-Checkly-Account` and the account ID copied in step 2 as the value. (For example, `<account_id>`)
On-premises instance	Enable this toggle when the Checkly instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Checkly is established. Verify Connection lists the tools the Checkly MCP server exposes and reads one check with the list-check-stats tool.
Click Create Instance.
In the Allowed tools and approvals section, review the tools Biggy loaded from the Checkly MCP server. Keep the read-only tools Biggy pre-selects. Biggy does not pre-select tools that create, update, delete, or run checks, or that read environment variables or usage. These tools wait for approval.
Biggy calls no tool on the Checkly MCP server until at least one tool is allowed.

Required permissions

Use one of the following Checkly API keys, depending on your Checkly plan:

Service API key: On Starter, Team, and Enterprise plans, create a service API key with the Read Only role.
User API key: On other plans, create a user API key. The API key has the same permissions as the associated user. User API keys start with cu_.

Older sk_ keys and account API keys do not work with this integration.

Do not use a write-capable role

Do not use the Read & Write, Read & Run, or Admin role for the API key. These roles let the key create, change, or run checks in your Checkly account.

Chronosphere

The Biggy Chronosphere integration gives Biggy access to metrics, logs, traces, events, and monitors in Chronosphere.

Biggy connects to your tenant's Chronosphere Model Context Protocol (MCP) server with a read-only API token, which Biggy sends as a bearer token. Biggy only reads from Chronosphere, and does not enable write access on the MCP server.

Required permissions

Biggy needs a Chronosphere API token with read-only access. Use one of the following:

A service account with a read-only role.
A personal access token.

Do not enable writes

Do not add the X-Chrono-MCP-Enable-Writes header to this integration. Biggy only reads from Chronosphere.

Configure the Chronosphere integration

To configure the integration:

In Chronosphere, create a service account or personal access token with a read-only role. Copy its API token.
Note your tenant's MCP server URL: https://<your-org>.chronosphere.io/api/mcp/mcp, where <your-org> is the name in your Chronosphere address. Local stdio and npx launches are not supported.

In the web app Chronosphere integration page, populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Chronosphere`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Chronosphere environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which Chronosphere projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Chronosphere MCP Server URL	The streamable HTTP endpoint of your tenant's Chronosphere MCP server, noted in step 2. (For example, `https://<your-org>.chronosphere.io/api/mcp/mcp`) Local `stdio` and `npx` launches are not supported.
Bearer Token	The Chronosphere API token copied in step 1. Biggy sends this value as a bearer token. Biggy encrypts this value at rest and masks it in the form.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. Do not add the `X-Chrono-MCP-Enable-Writes` header.
On-premises instance	Enable this toggle when the Chronosphere instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.
Connectivity	After entering the MCP server URL and bearer token, click Verify Connection to confirm that the connection to Chronosphere is established. Verify Connection also checks that the core read tools are present on the server.

Click Verify Connection to confirm that the connection to Chronosphere is established.
Click Create Instance.
After you save the instance, Biggy loads the tools that the Chronosphere MCP server exposes. In Allowed tools and approvals, review the selected tools. Biggy pre-selects the read-only tools. Keep the read-only tools Biggy pre-selects, including get_drop_rule and list_drop_rules.
Biggy calls no tool on this server until at least one tool is allowed.

ControlUp

The Biggy ControlUp integration gives Biggy access to machines, sessions, hosts, and alerts from the ControlUp digital employee experience platform.

Biggy connects to the ControlUp-hosted Model Context Protocol (MCP) server for your ControlUp region, and authenticates with a ControlUp API key sent in the api-key request header. After you save the connection, Biggy loads the tools the MCP server exposes, pre-selects the read-only ones, and gates writes and executions behind approval. Biggy calls no tool on this server until at least one tool is allowed.

Required permissions

The API key must belong to a ControlUp user with a role that includes the following permissions:

The view permissions of the built-in Viewer role, for each ControlUp product Biggy should read.
View settings
Manage API keys

Assign the role directly to the user

Only roles assigned directly to the user apply to API keys. Roles derived from SSO groups do not apply to API keys, so a user who receives the role only through an SSO group cannot authenticate with Biggy.

Configure the ControlUp integration

To configure the integration:

In ControlUp, go to Settings > Roles > New Role and create a read-only role for Biggy. Add the view permissions of the built-in Viewer role for each product Biggy should read, plus View settings and Manage API keys.
Go to Settings > User Settings. Open the user that Biggy acts as, go to Roles, and add the role you created in step 1.
Sign in to ControlUp as that user. In the upper-right corner, open the profile menu and select API Key Management, then click + Create new. Choose how long the key stays valid, and copy the key.
In Biggy, go to Integrations > Manage Integrations > ControlUp and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production ControlUp`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent notes (Optional)	Add notes to help Biggy understand your ControlUp environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which ControlUp projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Region	Select the region of your ControlUp organization. Biggy connects to the hosted MCP server for the selected region.
ControlUp MCP Server URL	The ControlUp-hosted MCP server address for the selected region. ControlUp sets this value, and it cannot be changed. (For example, `https://mcp.us.controlup.com/mcp` for the United States region)
API Key	The ControlUp API key you created in step 3. Biggy encrypts this value at rest and masks it in the form.
API Key Header Name	The name of the request header that carries the API key. Keep the default value, `api-key`, which is the header ControlUp reads the key from.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the ControlUp instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to test the connection before you save.
Click Create Instance.
In the Allowed tools and approvals section, review the tools Biggy loaded from the ControlUp MCP server. Select only the tools for the ControlUp product groups your organization uses. Tools in each product group share a name prefix:
- cu4d__: Desktops.
- vdi__: Virtual desktop infrastructure (VDI).
- cu4c__: Compliance.
- synthetic-monitoring__: Synthetic monitoring.
- workflows__: Workflows.
- platform__: Platform.
Keep the read-only tools Biggy pre-selects. The Azure sizing and MFA phone tools wait for approval before they run. Biggy calls no tool on the ControlUp MCP server until at least one tool is allowed.

Tool limit

The ControlUp MCP server lists 150 tools, and Biggy loads at most 116 tools at a time. Select only the product groups you use so that Biggy can load every tool you need.

Cloudflare

The Biggy Cloudflare integration gives Biggy access to your Cloudflare zones, DNS, firewall events, analytics, workers, and load balancers.

Biggy connects to the Cloudflare-hosted Model Context Protocol (MCP) server at https://mcp.cloudflare.com/mcp and authenticates with a Cloudflare API token that you create. Biggy calls the Cloudflare API through the server's execute tool.

The API token decides what Biggy can do in your Cloudflare account. Create the token with only Read permissions so that Biggy stays read-only.

Required permissions

Grant the Cloudflare API token the following read-only permissions:

Account Resources: Read
Zone: Read
Analytics: Read

Add Read permissions for any other Cloudflare product Biggy should see, such as Logs: Read or Zero Trust: Read. Do not add Edit permissions.

No Client IP address filtering

Do not enable Client IP Address Filtering on the API token. Biggy reaches Cloudflare through the Cloudflare-hosted MCP server, so an IP-filtered token fails to authenticate.

Configure the Cloudflare integration

To configure the integration:

In the Cloudflare dashboard, create an API token with Read permissions only. Include the permissions listed in Required permissions, and do not enable Client IP Address Filtering. Copy the token. Cloudflare displays the token value only once, so copy it before you leave the page.

In the web app Cloudflare integration page, populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Cloudflare`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Cloudflare environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which Cloudflare projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Cloudflare MCP Server URL	The address of the Cloudflare-hosted MCP server, `https://mcp.cloudflare.com/mcp`. Cloudflare sets this value, and it cannot be changed.
Bearer Token	The read-only Cloudflare API token you created in step 1. Biggy sends it as a bearer token to the Cloudflare MCP server.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the Cloudflare instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Cloudflare is established. Biggy checks the token by calling the Cloudflare whoami endpoint.
Click Create Instance.
In the Allowed tools and approvals section, select the execute tool. After you save the connection, Biggy loads the tools the server exposes and pre-selects the read-only ones. The execute tool is how Biggy reads the Cloudflare API, so Biggy cannot query Cloudflare until you allow it.
Choose how Biggy requests approval for execute calls. By default, every execute call asks for approval. If you switch the approval policy to Destructive only, an execute call that only reads runs will not ask, and every other execute call still asks. Read-only calls include GET requests and GraphQL analytics queries.

Keep approval on for execute

Never turn off Require approval for execute. Turning it off skips approval for write calls as well as read calls.

Coralogix

The Biggy Coralogix integration gives Biggy access to logs, traces, metrics, alerts, and dashboards in Coralogix.

Biggy connects to the Coralogix-hosted Model Context Protocol (MCP) server for your Coralogix region, and authenticates with a personal API key sent as a bearer token. Biggy loads the tools the MCP server exposes and pre-selects the read-only ones. Biggy calls no tool on this server until at least one tool is allowed.

Required permissions

The API key must belong to a Coralogix user whose role can read the following data:

Logs
Spans
Metrics
Alerts
Dashboards

Biggy only reads this data, so the user does not need an admin role.

Configure the Coralogix integration

To configure the integration:

In Coralogix, create a personal API key for a user whose role meets the required permissions. Copy the key, you will need it during configuration.
Note the Coralogix region that matches the URL you use to sign in to Coralogix. Biggy uses the hosted MCP server for that region.
In Biggy, go to Integrations > Manage Integrations > Coralogix and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Coralogix`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and are required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Coralogix environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which Coralogix projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Region	Select the Coralogix region that matches the URL you use to sign in to Coralogix. Biggy connects to the hosted MCP server for the selected region. (For example, US1 (AWS Ohio)). If you do not see your region, override in the MCP Server URL field.
Coralogix MCP Server URL (Optional)	Leave blank to use the Coralogix-hosted MCP server for the selected region, or enter your own Streamable HTTP endpoint. (For example, `https://api.us1.coralogix.com/mgmt/api/v1/mcp`) If your Coralogix GovCloud account offers the MCP server, enter `https://api.gov1.coralogixgov.us/mgmt/api/v1/mcp` as the URL override. Use the override for any region not listed in the Region menu.
Bearer Token	The personal API key copied in step 1. Biggy sends the key as a bearer token. Biggy encrypts this value at rest and masks it in the form.
Custom Headers (Optional)	The Coralogix connection does not need custom headers, so leave this field empty.
On-premises instance	Enable this toggle when the Coralogix instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.
Connectivity	After entering the connection details, click Verify Connection to confirm that the connection to Coralogix is established. Verify Connection lists the tools the Coralogix MCP server exposes.

Click Create Instance.
In the Allowed tools and approvals section, review the tools Biggy loads from the Coralogix MCP server. Keep the read-only tools Biggy pre-selects. Biggy calls no tool on the Coralogix MCP server until at least one tool is allowed.

Datadog

The Biggy Datadog integration is used for full-stack monitoring.

In Datadog, ensure the following permissions/scopes have been enabled:

apm_api_catalog_read
apm_read
apm_remote_configuration_read
apm_retention_filter_read
apm_service_catalog_read
apm_service_ingest_read
audience_management_read
continuous_profiler_pgo_read
continuous_profiler_read
debugger_read
error_tracking_read
events_read
incident_read
logs_read_data
logs_read_index_data
metrics_read
monitors_read
reference_tables_read
rum_apps_read
rum_retention_filters_read
rum_session_replay_read
synthetics_global_variable_read
synthetics_private_location_read
synthetics_read
timeseries_query

To configure the Datadog integration, populate the following fields:

Field	Description
Datadog Region	The region of your Datadog instance. If you access Datadog via datadoghq.eu, select EU. If not, choose your US region. Select from US, US3, or US5.
API Key	Your Datadog API key.
Application Key	Your Datadog application key with required read-only scopes.
Agent Notes	Add notes to help Biggy understand your Datadog environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

Downdetector

Use the Downdetector integration to give Biggy access to crowd-sourced outage signals on popular services.

To configure the Downdetector integration:

In Downdetector, obtain an API token.

In the web app Downdetector integration page, configure the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list.
Agent Notes	Add notes to help Biggy understand your Downdetector environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results.
Downdetector API Token	Enter the API token from Downdetctor, obtained in step 1.
On-premises Instance	Enable this toggle when the Downdetector instance is only reachable from inside your network, such as a cluster reachable only over Private Link. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to test the connection before you save.
Click Save Instance.

Dynatrace

The Biggy Dynatrace integration is used for application performance monitoring.

Ensure the following Dynatrace scopes/permissions have been enabled:

API v1 Scopes

DataExport
ReadConfig
ExternalSyntheticIntegration
ReadSyntheticData

API v2 Scopes

entities.read
events.read
metrics.read
problems.read
settings.read
logs.read
syntheticLocations.read
syntheticExecutions.read

To configure the Dynatrace integration, populate the following fields:

Field	Description
Dynatrace URL	The URL of your Dynatrace instance.
API Key	Your Dynatrace API key.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
Deployment Type	Select whether your Dynatrace integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
Agent Notes	Add notes to help Biggy understand your Dynatrace environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

Elasticsearch

The Biggy Elasticsearch integration is used for metrics monitoring.

Populate the following fields to set up the integration:

Field	Description
Authentication Method	Choose how you'd like to authenticate with this integration. The following methods are available: Basic Authentication - authenticate using an Elasticsearch username and password API Key Authentication - authenticate using an Elasticsearch API key Bearer Token Authentication - authenticate using an Elasticsearch bearer token
Elasticsearch Instance URL	Enter the base URL of the inbound Elasticsearch instance. Include the port if applicable. (For example, `https://<inbound-ip>:9200`)
Credentials	Enter the credentials that allow the integration to authenticate. If you selected the Basic Authentication method, enter your Elasticsearch username and password. If you selected API Key Authentication, enter an Elasticsearch API key. If you selected Bearer Token Authentication, enter an Elasticsearch bearer token.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
Deployment	Select whether your Elasticsearch integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
Elasticsearch Agent Notes	Add notes to help Biggy understand your Elasticsearch environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

Embrace (Cortex XCOR RUM)

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Embrace integration gives Biggy access to exceptions, logs, sessions, network performance, and both mobile and web app crashes from Embrace.

Biggy connects to the Embrace-hosted Model Context Protocol (MCP) server at https://mcp.embrace.io/mcp and authenticates with an Embrace service account token, which Biggy sends as a bearer token. Biggy only reads from Embrace.

Cortext XCOR RUM

Embrace is now Cortex XCOR RUM by Palo Alto Networks. The MCP server keeps the Embrace name.

Google Cloud

The Biggy Google Cloud integration lets Biggy read Google Cloud Monitoring metrics, alert policies, alerts, and Cloud Logging entries.

Biggy connects to the Google Cloud MCP server for the product you select, and authenticates with the JSON key of a Google Cloud service account. Each instance reads one product, either Cloud Monitoring or Cloud Logging. To give Biggy access to both products, add a second instance that uses the same service account key and select the other product.

Tool approvals

After you save the instance, Biggy loads the tools the Google Cloud MCP server exposes, pre-selects the read-only tools, and gates write and execution tools behind approval. Biggy calls no tool on this server until at least one tool is allowed.

Required permissions

Grant the Google Cloud service account the following IAM roles:

roles/mcp.toolUser
A role that can read the product you connect

Grant the roles in the project that owns the service account. This is the project shown as project_id in the service account JSON key. Verify Connection checks that project, so the connection test fails if the roles are granted elsewhere. Use read-only roles wherever they are enough.

The API for the product you connect must also be enabled in the project. The Google Cloud MCP server only responds for a project that has the product API enabled:

Cloud Monitoring: monitoring.googleapis.com
Cloud Logging: logging.googleapis.com

Configure the Google Cloud integration

To configure the integration:

Enable the API. In the Google Cloud project you want Biggy to read, enable the API for the product you will connect: the Cloud Monitoring API (monitoring.googleapis.com) or the Cloud Logging API (logging.googleapis.com).
In the same project, create a service account for Biggy. Grant it roles/mcp.toolUser and a role that can read the Cloud Monitoring or Cloud Logging API you chose in step 1.
Create a JSON key. On the service account's Keys tab, create a new key of type JSON and download it.
Restrict which MCP tools Biggy can call
Optionally, you can limit which Google Cloud MCP tools the service account may call by applying an IAM Deny policy to it.
In the web app, go to Integrations > Manage Integrations > Google Cloud and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Google Cloud`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and become required once a second instance exists.
Agent notes (Optional)	Add notes to help Biggy understand your Google Cloud environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. Add the default project ID here so Biggy knows which project to query. For example, also note which Google Cloud projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Product	Select the Google Cloud product this instance reads: Cloud Monitoring or Cloud Logging. One instance reads one product. To connect the other product, add a second instance with the same service account key.
Google Cloud MCP Server URL	The Google Cloud MCP server endpoint for the selected product. This value is set by Google Cloud and cannot be changed. (For example, `https://monitoring.googleapis.com/mcp` for Cloud Monitoring)
Service account key	Paste the full contents of the service account JSON key file downloaded from Google Cloud in step 3. The key is not shown again after you save the instance.
Scope (Optional)	The OAuth scope Biggy requests when it authenticates with the service account key. Leave this field blank to use the cloud-platform scope (`https://www.googleapis.com/auth/cloud-platform`).
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the Google Cloud instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.
Connectivity	After entering the connection details, click Verify Connection to confirm that the connection to Google Cloud is established. Biggy checks the project that owns the service account, shown as `project_id` in the JSON key.

In the Connectivity section, click Verify Connection to test the connection before you save.
Click Create Instance.
In the Allowed tools and approvals section, review the tools Biggy loaded from the Google Cloud MCP server. Biggy pre-selects the read-only tools and gates write and execution tools behind approval. Make sure at least one tool is allowed, because Biggy won't call any tool on this server until at least one is allowed.

Grafana

Use the Biggy Grafana integration for metrics monitoring. Use this integration for action plans, such as the Observability Agent.Observability Agent

Populate the following fields to set up the integration:

Field	Description
Authentication Method	Choose how you'd like to authenticate with this integration. The following methods are available: Basic Authentication - authenticate using a Grafana username and password Bearer Token Authentication - authenticate using a Grafana bearer token
Grafana Instance URL	Enter the base URL of the inbound Grafana instance. Include the port if applicable. (For example, `https://myinstance.grafana.net`).
Credentials	Enter the credentials that allow the integration to authenticate. If you selected the Basic Authentication method, enter your Grafana username and password. If you selected Bearer Token Authentication, enter a Grafana bearer token.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
Deployment Type	Select whether your Grafana integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
Connectivity	After entering the authentication method, instance URL, and credentials, click Verify Connection to ensure that the connection to Grafana is established. Click Update Data Schema to allow Biggy to retrieve and store relevant schema information for this integration. This helps Biggy understand how your data is structured, allowing for more accurate and efficient information retrieval.
Grafana Agent Notes	Add notes to help Biggy understand your Grafana environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, if your logs contain a specific field that is used to identify the type of application or service, define the purpose and function of that field here.

Grafana Loki

The Biggy Grafana Loki integration lets Biggy search your Grafana Loki logs with read-only LogQL queries.

Biggy connects to the Loki HTTP API directly. You can connect to self-hosted Loki, Grafana Enterprise Logs, Grafana Cloud, or a gateway in front of Loki.

The integration is read-only. Biggy runs small, time-bounded LogQL queries and never pushes or deletes logs.

Requirements

To use the integration, you need:

Network access to the Loki HTTP API, or to the gateway in front of it. Biggy queries Loki directly, not through a Grafana data source.
Loki 2.9 or later to use stats and volume queries.
Read access to the tenant or tenants that the instance names. For Grafana Cloud, use a token with the logs:read scope.
If Loki is only reachable from inside your network, a relay client assigned on the Relay Clients page.

Connect to a multi-tenant Loki

When multi-tenancy is enabled in Loki (auth_enabled: true), enter the tenant this connection reads in the Tenant ID (X-Scope-OrgID) field. Biggy sends this value as the X-Scope-OrgID header.

Query several tenants: Separate the tenant IDs with |. (For example, team-a|team-b) Use this format only when the Loki querier has multi_tenant_queries_enabled set.
Keep tenants separate: Add one instance for each team, and enter a single tenant ID in each instance.
Single-tenant Loki: Leave the Tenant ID (X-Scope-OrgID) field empty.

Configure the Grafana Loki integration

To configure the integration:

Copy the base URL of either Loki, or the gateway in front of it. Include any path prefix the deployment serves under. (For example, https://gateway.example.com/logs) Leave out /loki/api/v1, because Biggy appends it.
Gather the credentials for the authentication method you plan to use:
- Basic Auth: For Grafana Enterprise Logs, Grafana Cloud, or a gateway. For Grafana Cloud, use the Grafana Cloud instance ID as the username and a token with the logs:read scope as the password.
- Bearer Token: For a gateway that accepts a bearer token.
- No Authentication: For Loki inside your network that has no authentication in front of it.
In the web app, go to Integrations > Manage Integrations > Grafana Loki and click + New instance.

Populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Grafana Loki`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Grafana Loki environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which labels identify a service, team, or environment, such as `service_name`, `namespace`, or `env`. This helps Biggy build the right stream selectors.
Authentication method	Select how Biggy authenticates with Loki. The following methods are available: Basic Auth: A username and password or token. Use this method for Grafana Enterprise Logs, Grafana Cloud (instance ID and a `logs:read` token), or a gateway. Bearer Token: Sent as `Authorization: Bearer <token>`. Use this method for a gateway that takes a token. No Authentication: No credential header is sent. Use this method for a Loki inside your network that you reach through a relay client, optionally with a client certificate held on the relay.
Loki URL	The Loki or Loki gateway base URL, copied in step 1. Include any path prefix the deployment serves under. (For example, `https://loki.example.com`) Biggy calls the HTTP API under `/loki/api/v1`, so leave that path out. Plain `http://` URLs are accepted only for on-premises instances.
Tenant ID (X-Scope-OrgID) (Optional)	The tenant Biggy reads, sent as the `X-Scope-OrgID` header. Separate several tenant IDs with `\|` for a multi-tenant query. (For example, `team-a\|team-b`) Multi-tenant queries require `multi_tenant_queries_enabled` on the Loki querier. Leave this field empty when Loki runs without multi-tenancy. See Connect to a multi-tenant Loki for more information.
Username	This option only appears if you selected Basic Auth as the authentication method. Enter the username, or your Grafana Cloud instance ID.
Password	This option only appears if you selected Basic Auth as the authentication method. Enter the password or access token. For Grafana Cloud, enter a token with the `logs:read` scope. Biggy encrypts this value at rest and masks it in the form.
Bearer Token	This option only appears if you selected Bearer Token as the authentication method. Enter the token your gateway accepts. Biggy encrypts this value at rest and masks it in the form.
Credentials held on the relay client (Preview)	Enable this toggle to keep credentials on the relay client instead of in Biggy. Biggy stores only slot names. The relay client reads each value from a Kubernetes Secret mounted next to it and uses it for this instance alone, so the value never reaches Biggy. To rotate a credential, update the Secret. Assign this instance to a relay client on the Relay Clients page before you enable this toggle.
Token slot (Optional)	This option only appears if you enabled Credentials held on the relay client. The slot in the relay's `slots.json` file, and the key in its mounted Secret, whose value the relay sends to this instance. The relay sends the value in the header that `slots.json` sets: `Authorization: Bearer` by default, or another scheme. (For example, `vendor-token`)
Certificate slot (Optional)	This option only appears if you enabled Credentials held on the relay client. The slot in the relay's `slots.json` file whose client certificate the relay presents to this instance over mTLS (`tls.crt`, `tls.key`, and an optional `ca.crt`). (For example, `cortex-cert`) Leave this field empty when no client certificate is needed.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the Grafana Loki instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Grafana Loki is established.
Click Create Instance.

Honeycomb

The Biggy Honeycomb integration gives Biggy access to Honeycomb traces, queries, BubbleUp, triggers, and service level objectives (SLOs).

Biggy connects to the hosted Honeycomb Model Context Protocol (MCP) server with a Management API key. The key needs only read permissions, and Biggy uses it to read data from your Honeycomb team.

After you save the connection, Biggy loads the tools exposed by the Honeycomb MCP server and pre-selects the read-only ones. Read-only tools, such as run_query and run_bubbleup, run without asking.

Requirements

To use the integration, you need:

Honeycomb Intelligence enabled for your Honeycomb team. Without it, the Honeycomb MCP server lists no tools.
A Honeycomb Management API key with the required read permissions. Only Honeycomb team owners can enable Honeycomb Intelligence and create the key.

Required permissions

Grant the Honeycomb Management API key only the following permissions:

Model Context Protocol: Read
Environments: Read

Do not grant Write permissions. Biggy only reads from your Honeycomb team.

Configure the Honeycomb integration

To configure the integration:

In Honeycomb, enable Honeycomb Intelligence. Only a team owner can perform this step.
Go to Account > Team Settings > API Keys and create a Management API key with the Model Context Protocol: Read and Environments: Read permissions. Copy the key ID and secret key.

In the web app Honeycomb integration page, populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Honeycomb`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent notes (Optional)	Add notes to help Biggy understand your Honeycomb environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which Honeycomb projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Region	Select United States or Europe to match the region of your Honeycomb team.
Honeycomb MCP Server URL	The Honeycomb MCP server address. This value is autopopulated and cannot be changed. (For example, `https://mcp.honeycomb.io/mcp` for the United States region)
Bearer Token	Enter the Management API key you created in step 2 in the format `<key_id>:<secret_key>`. Biggy sends this value to Honeycomb as a bearer token.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. Do not add an `X-MCP-Toolset` header.
On-premises instance	Enable this toggle when the Honeycomb instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.
Connectivity	After entering the connection details, click Verify Connection to confirm that the connection to Honeycomb is established.

Click Create Instance.
In the Allowed tools and approvals section, review the tools that Biggy loaded from the Honeycomb MCP server. Keep the read-only tools that Biggy pre-selects, including run_query and run_bubbleup. Biggy calls no tool on the Honeycomb MCP server until at least one tool is allowed.

IBM Instana

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy IBM Instana integration gives Biggy access to applications, infrastructure, and events from IBM Instana through your mcp-instana server.

Biggy connects to IBM's mcp-instana Model Context Protocol (MCP) server over Streamable HTTP. Biggy sends your Instana API token and tenant base URL on each request, so the server does not need to store Instana credentials. You host and run the mcp-instana server in your own environment.

Biggy calls only the tools you allow on the server. Read-only lookups on the pre-selected tools run automatically, and every write or execution waits for approval.

Requirements

To use the integration, you need:

IBM's mcp-instana server, version 1.0.3, running in Streamable HTTP mode.
An HTTPS endpoint for the server at the /mcp path. Local stdio and npx launches are not supported.
An Instana API token.
The base URL of your Instana tenant. (For example, https://<tenant>.instana.io)

Serving more than one Instana tenant

If one mcp-instana server serves more than one Instana tenant, set INSTANA_CACHE_ENABLED=false on the server, or run one server per tenant.

Required permissions

Add the Instana API token permissions Biggy needs to use the pre-selected tools (events, websites, automation, synthetics, applications, and infrastructure), and note any additional permissions required for write or execution tools.

Connect through a bearer token gateway

If a gateway in front of the mcp-instana server checks a bearer token, the gateway does not pass the Instana headers from Biggy to the server. Store the Instana credentials on the server instead.

To connect through a bearer token gateway:

On the mcp-instana server, set the following environment variables:
- INSTANA_BASE_URL: Your Instana tenant URL. (For example, https://<tenant>.instana.io)
- INSTANA_API_TOKEN: Your Instana API token.
Do not add any custom headers that start with instana-.

Configure the IBM Instana integration

To configure the integration:

Start mcp-instana in Streamable HTTP mode:
```
mcp-instana --transport streamable-http
```
Expose the server over HTTPS at the /mcp path, and copy the full server URL. (For example, https://mcp-instana.internal.example.com/mcp)
In Instana, create or copy an API token for Biggy to use.
In the web app, open the IBM Instana integration page and click New instance.

Populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production IBM Instana`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your IBM Instana environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which IBM Instana projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Authentication Method	Select how Biggy authenticates with the mcp-instana server. The following methods are available: API Key Header (default): Biggy sends the API key in a request header that you name. Use this method when the server receives Instana credentials directly from Biggy. Bearer Token: Sent as `Authorization: Bearer <token>`. The standard for authenticated MCP servers. See Connect through a bearer token gateway for more information. No Authentication: No credentials are sent. This method is uncommon and typically only for MCP servers running on your network and accessed via a relay client.
IBM Instana MCP Server URL	The Streamable HTTP endpoint of your mcp-instana server, copied in step 2. (For example, `https://mcp-instana.internal.example.com/mcp`) Local `stdio` and `npx` launches are not supported.
Authentication	The required authentication information varies depending on the selected Authentication Method. API Key Header: enter the API Key value and API Key Header Name. The API Key Header Name is the name of the request header that carries the API key. Keep the default value, `instana-api-token`, which is the header mcp-instana reads the token from. Bearer Token: Enter the Bearer Token value.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. For the API Key Header method, add a header with the name `instana-base-url` and your Instana tenant URL as the value. (For example, `https://<tenant>.instana.io`)
On-premises instance	Enable this toggle when the mcp-instana server is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to the mcp-instana server is established.
Click Create Instance.
In the Allowed tools and approvals section, review the tools Biggy can call on the server. Biggy calls no tool on the server until at least one tool is allowed.
The following tools are selected by default:
- manage_events
- manage_websites
- manage_automation
- manage_synthetics
- manage_applications
- manage_infrastructure
Lookups on the selected tools run immediately. Changes made through any tool, and every call on the other tools, including lookups, wait for approval.

Icinga 2

The Biggy Icinga 2 integration gives Biggy check output, downtimes, comments, and host and service status from your Icinga 2 server.

Biggy connects to the Icinga 2 REST API with a dedicated ApiUser that has only read permissions. The integration is read-only. Biggy never acknowledges problems or schedules downtime, so no other permission is needed.

Requirements

To use the integration, you need:

Icinga 2 version 2.11 or later with the API feature enabled. To enable the API feature, run icinga2 feature enable api on the API node.
A dedicated ApiUser with only the read permissions listed in Required permissions.
If the Icinga 2 API certificate was not issued by a public certificate authority (CA), the Icinga 2 CA certificate in PEM format.
If the Icinga 2 API is not reachable from the internet, a relay client assigned on the Relay Clients page.

Required permissions

Grant the Icinga 2 ApiUser only the following permissions:

objects/query/Host
objects/query/Service
objects/query/HostGroup
objects/query/ServiceGroup
objects/query/Downtime
objects/query/Comment
status/query
filter-expression

Use a dedicated read-only user

Do not reuse root or an ApiUser with the * permission. Biggy accepts these users, but Verify Connection displays a warning when the user can write.

Configure the Icinga 2 integration

To configure the integration:

On the Icinga 2 API node, open /etc/icinga2/conf.d/api-users.conf and add a dedicated ApiUser object for Biggy with only the read permissions:

object ApiUser "biggy-readonly" {
  password = "<password>"
  permissions = [
    "objects/query/Host",
    "objects/query/Service",
    "objects/query/HostGroup",
    "objects/query/ServiceGroup",
    "objects/query/Downtime",
    "objects/query/Comment",
    "status/query",
    "filter-expression"
  ]
}

Run icinga2 daemon -C to validate the configuration, then run systemctl reload icinga2 to reload Icinga 2. Note the ApiUser object name and password. The object name is the value you enter in the API User field.
Note the Icinga 2 API address. Use the node's fully qualified domain name (FQDN), which is the name on its API certificate, and the API port. The default API port is 5665. (For example, https://icinga.example.com:5665) This is not the Icinga Web address.
If the Icinga 2 API certificate is signed by the Icinga 2 CA, copy the contents of /var/lib/icinga2/certs/ca.crt from the API node. Icinga 2 usually signs its API certificate with its own CA. Skip this step if the API certificate was issued by a public certificate authority.
In the web app, go to Integrations > Manage Integrations > Icinga 2 and click + New instance.

Populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Icinga 2`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Icinga 2 environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note host naming conventions and which host groups map to which services, so Biggy can pick the right hosts.
Icinga 2 API URL	Enter the Icinga 2 API address noted in step 3: the node FQDN with the API port. (For example, `https://icinga.example.com:5665`) If you leave out the port, Biggy adds the default port, `5665`. Biggy calls the REST API under `/v1`. Do not enter the Icinga Web address. Plain `http://` URLs are accepted only when On-premises instance is enabled.
API User	The ApiUser object name from `/etc/icinga2/conf.d/api-users.conf`, created in step 1. (For example, `biggy-readonly`)
Password	The password of the ApiUser, set in step 1. Biggy encrypts this value at rest and masks it in the form.
Icinga CA Certificate (PEM) (Optional)	If the Icinga 2 API certificate was signed by the Icinga 2 CA, paste the contents of `/var/lib/icinga2/certs/ca.crt` so Biggy can verify the server TLS certificate. Leave this field empty when the API certificate was issued by a public certificate authority.
On-premises instance	Enable this toggle when the Icinga 2 instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Icinga 2 is established.
Write warning
Biggy reads the host and service counts to test the connection, and displays a warning if the ApiUser can write.
Click Create Instance.

Juniper Mist

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Juniper Mist integration gives Biggy access to alarms, events, device stats, Marvis insights, and service-level expectations (SLEs) from Juniper Mist.

Biggy connects to the Juniper-hosted Mist Model Context Protocol (MCP) server at https://mcp.ai.juniper.net/mcp/mist and authenticates with a Mist API token that you create. All seven tools the Juniper Mist MCP server exposes are read-only, so Biggy only reads from your Mist organization.

Required permissions

Create an organization API token with the Observer access level. Observer access is enough for every tool Biggy calls.

Do not use a token with write access

Biggy only reads from Juniper Mist. Do not create the API token with an access level that allows writes.

Configure the Juniper Mist integration

To configure the integration:

In the Mist portal, go to Organization > Admin > Settings and select API Token > Create Token. Set Access Level to Observer and copy the key.
(Optional) Copy the Organization ID to limit Biggy to one Mist organization.
Note your Mist cloud. Your Mist portal address shows your cloud in the format manage.<cloud>.mist.com. For example, manage.ac2.mist.com is the Global 03 cloud.
(Optional) To limit Biggy to one Mist organization, copy the Organization ID from the same Settings page you used in step 1. Leave this step out to let Biggy use every organization the token can read.
In the web app, go to Integrations > Manage Integrations > Juniper Mist and click + New instance.

Populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Juniper Mist`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent notes (Optional)	Add notes to help Biggy understand your Juniper Mist environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which Mist sites and device types matter, naming conventions, and any investigation playbooks Biggy should follow.
Juniper Mist MCP Server URL	The address of the Juniper-hosted Mist MCP server, `https://mcp.ai.juniper.net/mcp/mist`. This field is read-only.
Mist API Token	The Observer-level organization API token you created in step 1. Biggy masks this value in the form.
Mist Cloud	Select the cloud that matches your Mist portal address (`manage.<cloud>.mist.com`), noted in step 2. The default is Global 01 (manage.mist.com). (For example, if your portal address is `manage.ac2.mist.com`, select Global 03)
Organization ID (Optional)	The Organization ID UUID copied in step 3. Biggy sends this value as the `X-Mist-Org-ID` header to limit Biggy to one organization. Leave this field blank to grant access to every organization the token can read.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the Juniper Mist instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Juniper Mist is established. Biggy signs in to the Juniper Mist MCP server and calls the get_mist_self tool.
Click Create Instance.
In the Allowed tools and approvals section, review the tools Biggy loaded from the Juniper Mist MCP server. All seven Mist tools are read-only, so Biggy pre-selects all of them. Biggy calls no tool on the Juniper Mist MCP server until at least one tool is allowed.

LogicMonitor

The LogicMonitor integration is used for infrastructure monitoring and observability.

To configure the LogicMonitor integration, populate the following fields:

Field	Description
Authentication Method	Choose how you'd like to authenticate with this integration. The following methods are available: LMv1 (Access Key) Bearer token
LogicMonitor URL	URL of your LogicMonitor instance. (for example `https://your-company.logicmonitor.com`)
Credentials	If you selected LMv1 (Access Key) as your authentication method, enter the Access ID and Access Key of the LogicMonitor account that Biggy should use for API interactions. If you selected Bearer Token as your authentication method, enter your LogicMonitor Bearer Token.
Deployment Type	Select whether your LogicMonitor integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
LogicMonitor Agent Notes	Add notes to help Biggy understand your LogicMonitor environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, enter explanations of custom fields and when or how they should be used to handle user queries.

Logz.io

The Biggy Logz.io integration gives Biggy access to logs, PromQL metrics, triggered alerts, insights, and dashboards in Logz.io.

Biggy connects to the Logz.io-hosted Model Context Protocol (MCP) server for your Logz.io region, and authenticates with a Logz.io API token sent in the X-API-TOKEN header.

After you save the connection, Biggy loads the tools the Logz.io MCP server exposes and pre-selects the read-only ones. Biggy runs the 27 read tools without approval. The four dashboard and folder write tools wait for approval. Biggy calls no tool on this server until at least one tool is allowed.

Logz.io Pro or Enterprise plan required

Logz.io API tokens and API access are only available on Pro and Enterprise plans.

Required permissions

Assign the Logz.io API token one of the following roles, based on what Biggy needs to read:

Read-only: The recommended role for the Biggy API token.
User: Required if Biggy should read Insights.
Admin: Required for drop filters.

Configure the Logz.io integration

To configure the integration:

In Logz.io, go to Settings > Tools > Manage Tokens > API tokens and select + New API token. Assign the token the Read-only role, or the User role if Biggy should read Insights. Copy the token, you will need it during configuration.
Identify your account region
In Logz.io, open Settings > General to find your account region. You can also identify some regions from your sign-in address:
Sign-in address
Region
app.logz.io
US East
app-eu.logz.io
Frankfurt
app-uk.logz.io
London
If your region is not listed above, use the region shown in Settings > General.

Sign-in address	Region
`app.logz.io`	US East
`app-eu.logz.io`	Frankfurt
`app-uk.logz.io`	London

Add the integration instance in Biggy

In Biggy, go to Integrations > Manage Integrations > Logz.io, click Configure, and then click Add Instance.

Enter the following information:

Field	Description
Instance Name	A human-readable name that identifies this instance, such as “Production Logz.io.”
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it, such as “EU production accounts.” Routing instructions are recommended for a single instance and required when configuring multiple instances.
Agent notes (Optional)	Add organization-specific context to help Biggy produce more accurate and consistent results. Include relevant projects and environments, naming conventions, and investigation playbooks.
Region	Select the account region identified in step 2. Biggy connects to the hosted MCP server for that region.
Logz.io MCP Server URL	The MCP server address for the selected region. This field is read-only.
API Key	Enter the API token created in step 1. Biggy encrypts this value at rest and masks it in the form.
API Key Header Name	Keep the default value, `X-API-TOKEN`. This is the request header Logz.io uses to read the token.
Custom Headers (Optional)	Add any additional HTTP headers required for requests. Enter a Header Name and Header Value for each header. Click + to add another.
On-premises instance	Enable this toggle only if the endpoint is reachable exclusively from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

Verify the connection and create the instance
In the Connectivity section, click Verify Connection. Verification tests connectivity, reads account information, and discovers the tools available from the Logz.io MCP server.
After verification succeeds, click Create Instance.
Review and save allowed tools
In Allowed MCP Tools, review the discovered tools and their approval settings. The available tools are discovered live, so their names and counts may change.
Keep the read-only tools you need enabled, and require approval for tools that modify dashboards or folders. At least one tool must be allowed before Biggy can execute tools on the Logz.io MCP server.
Click Save Instance to save your tool selections and approval settings.

M365 Service Health

The Biggy M365 Service Health integration gives Biggy access to the tenant-specific Microsoft 365 incidents and advisories shown in the Microsoft 365 admin center. Biggy reads this data through Microsoft Graph.

M365 Service Health is connected per Microsoft 365 tenant. Each instance signs in as a Microsoft Entra app registration that you create in that tenant, so add one instance for each tenant you want Biggy to see.

The integration is read-only. Biggy reads only the service health incidents and advisories in the Microsoft 365 admin center, and never reads mail, chat, or files.

Caution

Not included

Planned changes and the Message Center are not part of service health, so Biggy does not read them. Biggy also does not create alerts from this feed. Biggy reads service health only during investigations and chat.

Required permissions

Grant the Microsoft Entra app registration the following Microsoft Graph application permission:

ServiceHealth.Read.All

This is an application permission, not a delegated permission. Biggy signs in as the app, with no signed-in user. The permission is read-only and covers only the service health incidents and advisories in the Microsoft 365 admin center.

A Global Administrator or Privileged Role Administrator must grant admin consent for the permission in your tenant.

Who can see this data

Anyone granted this integration in Biggy can read service health for the whole tenant. In the Microsoft 365 admin center, the same view normally requires an admin role such as Service Support Administrator or Global Reader. Answers that Biggy posts in a Microsoft Teams or Slack channel are visible to everyone in that channel.

Configure the M365 Service Health integration

To configure the integration:

Register a single-tenant app for Biggy. In Microsoft Entra ID > App registrations > New registration, create an app for Accounts in this organizational directory only. No redirect URI is needed. For more information, see the Microsoft documentation.
App registrations, not Enterprise applications
Create the app in App registrations rather than Enterprise applications. The permission and the client secret are managed on the app registration.
Copy the Directory (tenant) ID and Application (client) ID from the app's Overview page.
Add the Microsoft Graph application permission. Open API permissions > Add a permission > Microsoft Graph > Application permissions and add ServiceHealth.Read.All. Select Application permissions, not Delegated permissions.
For more information, see the Microsoft Graph permissions reference.
Grant admin consent. On the same API permissions page, select Grant admin consent for your tenant and confirm. The permission's status changes to Granted.
This step requires a Global Administrator or Privileged Role Administrator. For more information, see the Microsoft Grant tenant-wide admin consent documentation.
Create a client secret. Under Certificates & secrets, select New client secret, pick an expiry that your rotation policy allows, and copy the secret Value immediately. Copy the value, not the Secret ID. Microsoft Entra shows the value only once.

In the web app integration page, populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production M365 Service Health`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and become required once a second instance exists.
Agent Notes (Optional)	Add notes to help Biggy understand your Microsoft 365 environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which Microsoft 365 services matter most to this tenant, such as Exchange Online, Microsoft Teams, or SharePoint Online, and which of your teams or applications depend on them.
Directory (tenant) ID	The Directory (tenant) ID GUID, copied from the app registration's Overview page in Microsoft Entra ID in step 1.
Application (client) ID	The Application (client) ID GUID of the app registration you created for Biggy, copied in step 1.
Client Secret	The client secret value created in step 4. Biggy encrypts this value at rest and masks it in the form. Client secrets expire, so rotate them in the app registration before they do.
Microsoft cloud	Selects the Microsoft Entra sign-in and Microsoft Graph endpoints. Commercial and GCC tenants use the global cloud, so leave this on Microsoft 365 (global, default; also GCC) unless the tenant is in GCC High or DoD, or is operated by 21Vianet. In that case, select the matching cloud.

Click Verify Connection to confirm that the connection to M365 Service Health is established.
Click Create Instance.

Mezmo (Formerly LogDNA)

The Biggy Mezmo integration lets Biggy search Mezmo (formerly LogDNA) logs in a single account or across every child account of an enterprise.

Biggy connects to the Mezmo API with a service key. An enterprise service key, lets Biggy search every child account of the enterprise. An account service key reaches one account. To search more than one account without an enterprise key, add one instance per account.

The integration is read-only. Biggy never changes views, alerts, pipelines, or account settings in Mezmo.

Required access

Biggy needs a Mezmo service key with the following read-only access:

Read logs (export)
Read views
Read enterprise child accounts (enterprise key only)

Configure the Mezmo integration

To configure the integration:

In Mezmo, go to Settings > Organization > API Keys and create a service key. For an enterprise account, create the key in the enterprise dashboard. Copy the key.
In Biggy, go to Integrations > Manage Integrations > Mezmo and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Mezmo`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Mezmo environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which apps belong to which services, and the words your account names use for environments.
API key	The Mezmo service key you created in step 1. Paste only the key, which starts with `ste_` or `sts_`. Do not add a `Token` or `Bearer` prefix. If you paste one, Biggy removes it. Biggy encrypts this value at rest and masks it in the form.
API base URL (Optional)	Leave this field empty to use `https://api.mezmo.com`. Set it only if you use an EU or self-hosted Mezmo API host.
Default environment	Only used with an enterprise key. Select the environment Biggy picks when the candidate accounts differ only by environment: No default (ask when ambiguous), Production, Non-production, or Pre-production. The default is No default (ask when ambiguous). Leave the default unless your account names differ only by environment.
Pinned accounts (Optional)	Only used with an enterprise key. Enter up to five accounts, comma-separated. Identify each account by its short account value, its long `account_id`, or its exact name. (For example, `a1b2c3d4e5, Payments_Prod`) Biggy searches the pinned accounts when a question names no account, and prefers them when an account name is ambiguous.
Account name filter (Optional)	Only used with an enterprise key. Limit this instance to accounts whose name contains this text. (For example, `Billing` or `*_Prod`) Leave this field empty to include all accounts.
Lines per search	The number of log lines one search returns to Biggy. Enter a value from 10 to 500. The default is 50.
Characters per line	The number of characters Biggy keeps from each log line before clipping it. Enter a value from 200 to 4,000. The default is 1,000.

In the Connectivity section, click Verify Connection to confirm that the connection to Mezmo is established.
Click Create Instance.

Account scope for enterprise keys

If your enterprise has accounts whose names differ only by environment, such as Payments_Prod and Payments_Staging, set Default environment and Pinned accounts. This helps Biggy search the right account when a question does not name one.

Microsoft SCOM

The Biggy Microsoft SCOM integration provides Biggy with access to alerts, health states, and performance counters from Microsoft System Center Operations Manager (SCOM).

Biggy connects to the SCOM Web Console REST API with a dedicated domain account in the Operations Manager Read-Only Operator role.

The integration is read-only. Biggy never resolves alerts or changes overrides, so no other role is needed.

Requirements

To use the integration, you need:

SCOM 2019 or later with the Web Console REST API.
A dedicated domain account assigned to the Operations Manager Read-Only Operator role. No other role is needed.
If the Web Console certificate was not issued by a public certificate authority, the private CA certificate chain in PEM format.
If the SCOM Web Console is not reachable from the internet, a relay client assigned on the Relay Clients page.

Configure the Microsoft SCOM integration

To configure the integration:

In Operations Manager, create a dedicated domain account for Biggy and add it to the Read-Only Operator role.
Copy the SCOM Web Console URL. (For example, https://scom-web.example.com)

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Microsoft SCOM`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Microsoft SCOM environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which groups map to which services, naming conventions, and the servers that matter most during an incident.
Web Console URL	Enter the SCOM Web Console URL copied in step 2. (For example, `https://scom-web.example.com`) Biggy calls the REST API under `/OperationsManager`. Pasting the `/OperationsManager` path also works.
Username	The dedicated read-only domain account you created for Biggy in step 1. Enter the username in the format `<DOMAIN>\<username>`.
Password	The password for the SCOM domain account. Biggy encrypts this value at rest and masks it in the form.
Custom CA Certificate (PEM) (Optional)	If the SCOM Web Console certificate was not issued by a public certificate authority, paste the CA certificate chain (PEM) so Biggy can verify the server TLS certificate.
On-premises instance	Enable this toggle when the Microsoft SCOM instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Microsoft SCOM is established. Biggy logs in with the account credentials and runs one empty alert query.
Click Create Instance.

Troubleshoot the connection

If verification fails, the type of failure points to the cause:

Rejected login: The username or password is wrong.
Refused alert query: The account is not in the Read-Only Operator role.

Nagios XI

The Biggy Nagios XI integration gives Biggy host and service status, check output, and comments from your Nagios XI server.

Biggy connects to the Nagios XI REST API with the API key of a dedicated read-only user. The integration is read-only. Biggy never acknowledges problems or schedules downtime, so no other permission is needed.

Requirements

To use the integration, you need:

Nagios XI 2024 or later with the REST API. Nagios Core is not supported.
A dedicated Nagios XI user with API and read-only access.

Configure the Nagios XI integration

To configure the integration:

In Nagios XI, create a dedicated user for Biggy. Enable Read-only access and API access for the user.
Sign in to Nagios XI as the user you created in step 1 and open My Account. Copy the key shown under API Key.
Populate the following fields in the web app to set up the integration:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Nagios XI`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Nagios XI environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note host naming conventions and which host groups map to which services, so Biggy can pick the right hosts.
Nagios XI URL	Enter the Nagios XI URL. (For example, `https://nagios.example.com/nagiosxi`) Biggy calls the REST API under `/nagiosxi/api/v1`. Entering the bare host also works. Plain `http://` URLs are accepted only when On-premises instance is enabled.
API Key	The API key of the read-only Nagios XI user, copied in step 2. Biggy encrypts this value at rest and masks it in the form.
Custom CA Certificate (PEM) (Optional)	If your Nagios XI server certificate was not issued by a public certificate authority, such as a private or self-signed certificate, paste the CA certificate chain (PEM) so Biggy can verify the server TLS certificate.
System Time Zone	Select the system time zone configured in your Nagios XI instance. Nagios XI reports check and comment times in the server's local time, so select the time zone the Nagios XI server runs in to ensure dates and times are interpreted correctly. The default is Coordinated Universal Time (UTC).
On-premises instance	Enable this toggle when the Nagios XI instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

After entering the connection details, click Verify Connection to confirm that the connection to Nagios XI is established. Verify Connection reads the status of one host to test the connection.

Click Create Instance to save the integration.

NetScout nGeniusONE

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy NetScout nGeniusONE integration gives Biggy access to sites, probe health, applications, services, and alert thresholds from NetScout nGeniusONE.

Biggy connects to the nGeniusONE REST API with a dedicated read-only user. Biggy sends the user's credentials as HTTP Basic authentication on every request.

The integration is read-only. Biggy reads inventory, sites, applications, services, alert thresholds, and probe and server health. Biggy never creates, changes, or deletes anything in nGeniusONE.

Active alerts are not read

The nGeniusONE REST API has no alert feed, so Biggy does not read active alerts from nGeniusONE.

To include nGeniusONE alerts in your investigations, send them to BigPanda through nGeniusONE alert forwarding, using syslog, SNMP trap, or email. The alerts arrive in BigPanda as events, and Biggy adds the probe health, site, service, and threshold context around them.

Requirements

To connect NetScout, you need:

nGeniusONE 6.3 or later with the REST API enabled.
A dedicated nGeniusONE user with a read-only role and REST API access. Biggy will reject write access.
If the nGeniusONE web certificate is self-signed or was issued by a private certificate authority, the CA certificate in PEM format.
If the nGeniusONE server is not reachable from the internet, a relay client assigned on the Relay Clients page.

Configure the NetScout nGeniusONE integration

To configure the integration:

In the nGeniusONE console, create a dedicated user for Biggy. Assign the user a read-only role and enable REST API access.
Copy the nGeniusONE server address, including the web port. Use the host name the server certificate was issued for. (For example, https://ngenius.example.com:8443)
If the nGeniusONE web certificate is self-signed or was issued by a private certificate authority, copy the CA certificate in PEM format.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production NetScout nGeniusONE`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your nGeniusONE environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which sites, probes, and nGeniusONE services belong to which applications so Biggy can pick the right records.
nGeniusONE URL	Enter the nGeniusONE server address on its web port, copied in step 2. (For example, `https://ngenius.example.com:8443`) If you leave out the port, Biggy adds port `8443`. Biggy calls the REST API under `/ng1api/ncm`. Plain `http://` addresses are accepted only for on-premises instances.
API User	The dedicated read-only nGeniusONE user with REST API access that you created in step 1. (For example, `biggy-readonly`)
Password	The password for the nGeniusONE API user. Biggy encrypts this value at rest and masks it in the form.
nGeniusONE CA Certificate (PEM) (Optional)	If the nGeniusONE web certificate is self-signed or was issued by a private certificate authority, paste the CA certificate (PEM) that signed it so Biggy can verify the server TLS certificate. Leave this field empty when the certificate is from a public certificate authority.
On-premises instance	Enable this toggle when the NetScout nGeniusONE instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to NetScout nGeniusONE is established. Biggy reads the nGeniusONE server health to test the connection.
Click Create Instance.

New Relic

The New Relic - Biggy integration is used to retrieve data from application performance monitoring (APM), metrics, logs, and infrastructure telemetry.

Required Permissions

To ensure Biggy has the access it needs to perform necessary functions, either the New Relic Read Only role must be granted, or a custom role containing the following permissions:

NRQL query execution
Entity read (APM, Infrastructure, Browser, Mobile, Synthetics, Workloads, Dashboards)
Alert policies read
Alert issues and incidents read
Synthetics monitor read
Topology read

To configure the New Relic integration:

In New Relic, create or choose a dedicated integration user with access to the account that the Biggy should query.
In the New Relic API Keys page, generate a user API key for the user selected in step 1 and copy it.
API key restrictions
Do not use License, Browser, Mobile, or retired REST API keys
In New Relic Account Settings, copy the target New Relic account ID.

Populate the following fields in the web app New Relic integration page:

Field	Description
New Relic API Base URL	Base URL for your New Relic region. (For example, `https://api.newrelic.com` for US or `https://api.eu.newrelic.com` for EU)
New Relic Account ID	New Relic account ID copied in step 3.
New Relic User Key	User API key copied in step 2.
Custom Headers (optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
Deployment Type	Select whether your New Relic integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
New Relic Agent Notes	Add notes to help Biggy understand your New Relic environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, enter explanations of custom fields and when or how they should be used to handle user queries.

OpsRamp

The OpsRamp integration is used for hybrid IT infrastructure monitoring, alerting, and resource management.

Required permissions

The following OpsRamp permissions must be enabled to use the integration:

Alerts: View, Search
Resources: View, Search
Metrics: View, Query
Incidents/Tickets: View, Search
Service Maps: View
Topology: View

To configure the integration:

In OpsRamp, go to Setup > Integrations and install a custom integration. Be sure to copy your Key, Secret, and API Endpoint.
Go to Setup > Accounts and copy your Tenant ID.

In the web app, configure the following fields:

Field	Description
OpsRamp API Endpoint	The API endpoint from your custom integration, copied from the integration setup page in step 1. (for example, `https://api.opsramp.com`)
Integration Key	OpsRamp integration key, copied from the integration setup page in step 1.
Integration Secret	OpsRamp integration secret, copied from the integration setup page in step 1.
Tenant ID	OpsRamp tenant ID, copied from the OpsRamp Accounts page in step 2.
Custom Headers	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
Deployment Type	Select whether your OpsRamp integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
OpsRamp System/Schema Nuances	Add notes to help Biggy understand your OpsRamp environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, enter explanations of custom fields and when or how they should be used to handle user queries.

Oracle Enterprise Manager (OEM)

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Oracle Enterprise Manager (OEM) integration gives Biggy access to incidents, events, target status, metrics, and blackouts from Oracle Enterprise Manager Cloud Control.

Biggy connects to the Enterprise Manager REST API via a dedicated Enterprise Manager administrator with view-only privileges.

The integration is read-only. Biggy never clears or suppresses incidents, edits blackouts, or runs jobs, so no additional privileges are needed.

Requirements

To use the integration, you need:

Enterprise Manager Cloud Control 13.5 or later. The Enterprise Manager REST API exists only on Cloud Control 13.5 and later, so earlier releases cannot be connected. For more information, see the Oracle Enterprise Manager REST API documentation.
A dedicated Enterprise Manager administrator with view privileges only. Do not reuse SYSMAN, a super administrator, or any account with write privileges.
If the Enterprise Manager console certificate was not issued by a public certificate authority, the CA certificate that signed it in PEM format.
If the Oracle Management Service (OMS) is not reachable from the internet, a relay client assigned on the Relay Clients page.

Required permissions

Grant the dedicated Enterprise Manager administrator one of the following:

The EM_ALL_VIEWER role.
The View privilege on each target Biggy may read.

Biggy only reads from Enterprise Manager, so the administrator does not need any other role or privilege.

Configure the Oracle Enterprise Manager integration

To configure the integration:

In the Cloud Control console, create a dedicated administrator for Biggy. (For example, BIGGY_READONLY) Grant the administrator the EM_ALL_VIEWER role or the View privilege on each target Biggy may read.
Copy the OMS address. Use the Oracle Management Service host and its console HTTPS port. (For example, https://oms.example.com:7803) Do not copy a console page URL, such as /em/faces/....
Enterprise Manager usually signs its console certificate with its own CA. If the certificate was not issued by a public certificate authority, copy the CA certificate in PEM format.
In Biggy, go to Integrations > Manage Integrations > OEM and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production OEM`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Oracle Enterprise Manager environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note target naming conventions and which target groups map to which services, so Biggy can pick the right targets.
OMS URL	The Oracle Management Service address on its console HTTPS port, copied in step 3. (For example, `https://oms.example.com:7803`) If you leave out the port, Biggy adds the default port, 7803. Biggy reads the REST API under `/em/api`, which requires Enterprise Manager 13.5 or later. Plain `http://` is accepted only for on-premises instances.
EM User	The Enterprise Manager administrator user name you created for Biggy in step 2. (For example, `BIGGY_READONLY`)
Password	The password for the EM user. Biggy encrypts this value at rest and masks it in the form.
EM CA Certificate (PEM) (Optional)	If the OMS console certificate was not issued by a public certificate authority, paste the CA certificate that signed it (PEM) so Biggy can verify the server TLS certificate. Leave this field empty when the certificate is from a public certificate authority.
On-premises instance	Enable this toggle when the Oracle Enterprise Manager instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Oracle Enterprise Manager is established. Biggy calls the REST API and reads the targets the EM user can see.
Click Create Instance.

Palo Alto Panorama

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Palo Alto Panorama integration gives Biggy access to managed firewalls, device groups, configuration changes, system logs, and commit and push jobs, from Palo Alto Networks Panorama.

Biggy connects to the Panorama XML API via a dedicated administrator with the Superuser (read-only) role. This role lets Biggy read Panorama and every device group, template, and managed firewall, and run the XML API in a read-only state. Each instance connects to one Panorama deployment. To connect another Panorama deployment, add another instance.

The integration is read-only. Biggy never commits, pushes, or changes configuration.

Requirements

To use the integration, you need:

A dedicated local, RADIUS, TACACS+, or LDAP administrator on Panorama with the Superuser (read-only) role. No other privileges are needed.
Either a Panorama API key generated for that administrator, or the administrator's username and password.
If Panorama uses its default self-signed management certificate or a certificate issued by a private certificate authority, the certificate or CA certificate chain in PEM format.
If Panorama is not reachable from the internet, a relay client assigned on the Relay Clients page.

SAML administrators are not supported

SAML administrators cannot use the Panorama XML API. Create the Biggy administrator as a local, RADIUS, TACACS+, or LDAP administrator.

Configure the Palo Alto Panorama integration

To configure the integration:

In Panorama, open the Panorama tab and select Administrators.
Add a local, RADIUS, TACACS+, or LDAP administrator for Biggy (for example, biggy-readonly), and assign it the Superuser (read-only) role. Do not use a SAML administrator.
Choose how Biggy authenticates with Panorama:
- API Key: Run the keygen request once with the administrator's username and password, then copy the value of the <key> element from the response:
```
POST https://<panorama>/api/?type=keygen
```
  Send the administrator's credentials in the user and password parameters.
- Username & Password: Skip the keygen request. Biggy generates an API key from the administrator's credentials when it connects and keeps the key in memory only. Use this method when your Panorama API key lifetime is short.
Copy the Panorama management address (For example, https://panorama.example.com). If Panorama runs as a high availability (HA) pair, use the management address of the active Panorama peer or a floating name.
If the Panorama management interface has a permitted IP list, add the relay host address to it.
If Panorama uses its default self-signed management certificate or a certificate issued by a private certificate authority, copy the certificate or the CA certificate chain in PEM format.
In the web app, go to Integrations > Manage Integrations > Palo Alto Panorama and click + New instance.

Populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Palo Alto Panorama`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production firewalls`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Palo Alto Panorama environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which device groups or template stacks map to which sites or applications. This information helps Biggy pick the right firewalls.
Authentication Method	Select how Biggy authenticates with Panorama: API Key: Biggy authenticates with the API key you generated in step 2. Username & Password: Biggy generates an API key from the administrator's credentials at connect time and keeps it in memory only. Use this method when your API key has a short lifetime.
Panorama URL	Enter the Panorama management address. (For example, `https://panorama.example.com`) Biggy calls the XML API under `/api/`. Pasting a URL that includes the `/api/` path also works. Plain `http://` addresses are accepted only on an on-premises instance.
API Key	This option only appears if you selected API Key as the authentication method. The value of the `<key>` element returned by the keygen request. Biggy encrypts this value at rest and masks it in the form.
Username	This option only appears if you selected Username & Password as the authentication method. The dedicated read-only Panorama administrator you created for Biggy (For example, `biggy-readonly`)
Password	This option only appears if you selected Username & Password as the authentication method. The password for the Panorama administrator. Biggy encrypts this value at rest and exchanges it for an API key at connect time.
Custom CA Certificate (PEM) (Optional)	Panorama ships with a self-signed management certificate. Paste that certificate, or the certificate chain of your private CA, in PEM format so Biggy can verify the server TLS certificate.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
System Time Zone	Select the system time zone configured in your Palo Alto Panorama instance. This ensures dates and times are correctly interpreted. The default value is Coordinated Universal Time (UTC). Set this field if Verify Connection reports that Biggy cannot read the time zone from Panorama.
On-premises instance	Enable this toggle when the Palo Alto Panorama instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Palo Alto Panorama is established.
Click Create Instance.

API key expiration

A Panorama API key stops working when the administrator's password changes, the administrator is deleted, or the API key lifetime ends. To rotate a token, generate a new key, edit this instance with the new key, and click Verify Connection again. To avoid manual key rotation, use the Username & Password method instead.

Pingdom

The Biggy Pingdom integration gives Biggy access to outages, uptime summaries, alert history, and uptime and transaction check results from Pingdom.

Biggy connects to the Pingdom API at https://api.pingdom.com with a read-only API token. One token reads the whole Pingdom account, so add one instance for each Pingdom account you want Biggy to see.

The integration is read-only. Biggy never pauses, creates, or edits checks, alerts, or maintenance windows.

SolarWinds Observability accounts are not supported

Pingdom accounts that have already moved to SolarWinds Observability are not supported by this integration.

Requirements

To use the integration, you need:

A Pingdom user with the account Owner or Admin role. Only an Owner or an Admin can create API tokens.
A Pingdom API token with Read access.

Configure the Pingdom integration

To configure the integration:

Sign in to Pingdom at https://my.pingdom.com as the account Owner or an Admin.
Open the Pingdom API token page. The location depends on which Pingdom menu your account uses:
- Classic menu: Open Integrations > The Pingdom API.
- Newer menu: Click Settings (the gear icon), then select Pingdom API.
You can also go directly to https://my.pingdom.com/app/api-tokens.
Click Add API token. Name the token (for example, Biggy), set Access level to Read access, then click Generate token.
Copy the token.
In Biggy, go to Integrations > Manage Integrations > Pingdom and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Pingdom`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Pingdom environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which checks or tags belong to which services, so Biggy can pick the right checks during an investigation.
API token	The read-access API token copied in step 4. Paste only the token. If you paste a value that starts with a `Bearer` prefix, Biggy removes the prefix. Biggy encrypts this value at rest and masks it in the form. Biggy calls `api.pingdom.com` directly, so there is no URL to enter.
On-premises instance	Enable this toggle only if your network policy requires Pingdom traffic to go through a relay. Requests then route through a relay client assigned on the Relay Clients page. The relay only needs to reach `https://api.pingdom.com`.

In the Connectivity section, click Verify Connection to confirm that the connection to Pingdom is established. Biggy reads one check and shows how many uptime checks the token can see.
Click Create Instance.

Prometheus

The Biggy Prometheus integration is used for metrics monitoring.

Configure the following fields to set up the integration:

Field	Description
Prometheus Instance URL	Enter the base URL of the inbound Prometheus instance. Include the port, if applicable. (For example, `https://<prometheus-dns-name>.io` or `https://<prometheus-ip>:9090`).
Username and Password	Add credentials of the Prometheus account that Biggy should use for API interactions.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
Deployment Type	Select whether your Prometheus integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
Connectivity	After entering the instance URL, credentials, and deployment type, click Verify Connection to ensure that the connection to Prometheus is established. Click Update Data Schema to allow Biggy to retrieve and store relevant schema information for this integration. This helps Biggy understand how your data is structured, allowing for more accurate and efficient information retrieval.
Prometheus Agent Notes	Add notes to help Biggy understand your Prometheus environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, if your logs contain a specific field that is used to identify the type of application or service, define the purpose and function of that field here.

PRTG

The Biggy PRTG integration gives Biggy access to alarms, channel history, probes, groups and sensor and device status from PRTG.

Biggy connects to the PRTG Model Context Protocol (MCP) server that runs on your PRTG core server, and authenticates with a read-only PRTG API key sent as a bearer token. PRTG refuses every write that a read-only key sends, so Biggy only reads from PRTG.

After you save the connection, Biggy loads the tools the PRTG MCP server exposes and pre-selects the read-only ones. Read-only tools run immediately, and other tools wait for approval.

Requirements

To use the integration, you need:

PRTG 26.3.124 or later, with the new UI and API v2 turned on.
The PRTG MCP server turned on, on the PRTG core server.
A PRTG API key with access level Read.
If the PRTG server is only reachable from your private network, a relay client assigned on the Relay Clients page.

Required permissions

Create the PRTG API key with access level Read. Biggy only reads from PRTG, so the key does not need a higher access level.

Configure the PRTG integration

To configure the integration:

Turn on the PRTG MCP server. On the PRTG core server, add mcp under enabledfeatures in appserver.config.yml, then restart the PRTG application server.
Create a read-only API key. In PRTG, go to Setup > Account Settings > My Account > API Keys and add a key with access level Read. Copy the key.
Note your PRTG MCP server URL: https://<server>:1616/api/v2/mcp, where <server> is the address of your PRTG core server. Local stdio and npx launches are not supported.
In the web app, go to Integrations > Manage Integrations > PRTG and click + New instance.

Populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production PRTG`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent notes (Optional)	Add notes to help Biggy understand your PRTG environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which PRTG projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
PRTG MCP Server URL	The Streamable HTTP endpoint of your PRTG MCP server, noted in step 3. (For example, `https://prtg.example.com:1616/api/v2/mcp`) Local `stdio` and `npx` launches are not supported.
Bearer Token	The read-only PRTG API key you created in step 2. Biggy sends this value in the `Authorization: Bearer` header. Biggy encrypts this value at rest and masks it in the form.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the PRTG instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to PRTG is established. Biggy checks the connection by reading the PRTG version.
Click Create Instance.
In the Allowed tools and approvals section, review the tools Biggy loaded from the PRTG MCP server. Biggy pre-selects the read-only tools and gates writes and executions behind approval.
Biggy calls no tool on the PRTG MCP server until at least one tool is allowed.

SAP Cloud ALM

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy SAP Cloud ALM integration provides Biggy with access to SAP system health, monitoring events, jobs, and exceptions in SAP Cloud ALM.

SAP Cloud ALM is connected per tenant. One instance reads every SAP system in that tenant's landscape, so add another instance only when you want Biggy to see another tenant. Biggy connects to the SAP Cloud ALM API with the OAuth client credentials from an SAP Cloud ALM API service key that you create in SAP Business Technology Platform (BTP).

The integration is read-only. Biggy never changes SAP Cloud ALM or the SAP systems it monitors.

Automatic routing

When an incident names an SAP system by its system ID, SID, or hostname, Biggy routes the question to the instance whose landscape holds that system. You don't need to add routing instructions.

Required permissions

In SAP BTP, grant the SAP Cloud ALM API service instance the following read scopes:

calm-api.landscape.read
calm-api.analytics.read
calm-api.analytics.providers.read
calm-api.hm.read
calm-api.iep.read
calm-api.jobs.read
calm-api.exm.read
calm-api.integration-monitoring.read

Caution

Grant in SAP BTP

Grant the scopes on the SAP Cloud ALM API service instance in SAP BTP, not on the service key. Every service key you create for the instance inherits the instance's scopes.

Configure the SAP Cloud ALM integration

To configure the integration:

Create the SAP Cloud ALM API service instance. In the SAP BTP subaccount where SAP Cloud ALM is subscribed, open Services, then select Service Marketplace. Choose SAP Cloud ALM API and create an instance. In the parameters step, grant the read scopes listed in Required permissions. The following example grants all of them:

{
  "xs-security": {
    "xsappname": "biggy-cloud-alm-api",
    "authorities": [
      "$XSMASTERAPPNAME.calm-api.landscape.read",
      "$XSMASTERAPPNAME.calm-api.analytics.read",
      "$XSMASTERAPPNAME.calm-api.analytics.providers.read",
      "$XSMASTERAPPNAME.calm-api.hm.read",
      "$XSMASTERAPPNAME.calm-api.iep.read",
      "$XSMASTERAPPNAME.calm-api.jobs.read",
      "$XSMASTERAPPNAME.calm-api.exm.read",
      "$XSMASTERAPPNAME.calm-api.integration-monitoring.read"
    ]
  }
}

For more information, see the SAP Cloud ALM documentation.

Create a service key. On the new service instance, create a service key with the default credential type. The key inherits the instance's scopes.
Use the default credential type
A certificate (x509) service key has no client secret and cannot be used with this integration.
In the web app, go to Integrations > Manage Integrations > SAP Cloud ALM and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production SAP Cloud ALM`)
Notes (Optional)	Describe what this instance covers for your own reference. Biggy routes requests to this instance automatically by SAP system ID, SID, or hostname, so routing instructions are not needed.
Agent Notes (Optional)	Add notes to help Biggy understand your SAP Cloud ALM environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which SAP systems back which business services, your SID naming conventions, and which job and interface names matter most.
Paste service key JSON (Optional)	An optional shortcut for populating the connection fields. Paste the whole service key JSON from SAP BTP, then click Fill fields from service key to populate the API Base URL, Token URL, Client ID, and Client Secret fields. Biggy saves only those four values. The pasted JSON is not saved.
API Base URL	The `endpoints.Api` value from the service key. The URL must use HTTPS on an `*.alm.cloud.sap` host. (For example, `https://<tenant>.<region>.alm.cloud.sap/api`)
Token URL	The `uaa.url` value from the service key. The URL must use HTTPS on an `.hana.ondemand.com` or `.alm.cloud.sap` host. Biggy requests tokens from its `/oauth/token` endpoint. (For example, `https://<subdomain>.authentication.<region>.hana.ondemand.com`)
Client ID	The `uaa.clientid` value from the service key. The value typically begins with `sb-`.
Client Secret	The `uaa.clientsecret` value from the service key. Biggy encrypts this value at rest and masks it in the form.
On-premises instance	Enable this toggle when the SAP Cloud ALM instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.
Topology Indexing	When enabled, Biggy adds topology data from this integration to the knowledge graph.
Included environments	Select the SAP environments Biggy may route to and read from in this tenant. Biggy matches systems by their landscape role in SAP Cloud ALM, and never routes to or queries systems outside the selection. Defaults to Production. Add Quality, Test, or other environments only if Biggy should investigate them too.

In the Connectivity section, click Verify Connection to confirm that the connection to SAP Cloud ALM is established.
Click Create Instance.

ScienceLogic SL1

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy ScienceLogic SL1 integration gives Biggy access to events, devices, topology, device logs, and performance data from ScienceLogic SL1.

Biggy connects to the SL1 REST API with a dedicated read-only SL1 user. Biggy can authenticate with the user's name and password or, on SL1 12.5.20 or later, with an API key created for that user.

The integration is read-only. Biggy never acknowledges, clears, or masks events, edits devices, or creates tickets, so no other permission is needed.

Requirements

To use the integration, you need:

SL1 (EM7) 11.x or later. API key authentication requires SL1 12.5.20 or later.
A dedicated SL1 user with a user policy that includes the required access keys.
The SL1 user must be a member of every organization Biggy should see.
If the SL1 appliance's TLS certificate was issued by a private certificate authority, the CA certificate in PEM format.
If the SL1 appliance is not reachable from the internet, a relay client assigned on the Relay Clients page.

Required permissions

Assign the dedicated SL1 user a user policy with these access keys include the following:

API access hooks
Event/View
Device/View
Org/View

These access keys grant API access and view rights on events, devices, and organizations. SL1 scopes visibility by organization, so an SL1 user only sees the devices and events of the organizations it belongs to. Make the user a member of every organization Biggy should see.

Configure the ScienceLogic SL1 integration

To configure the integration:

In SL1, go to System > Manage > User Accounts and create a dedicated user for Biggy.
Assign the user a user policy whose access keys include the permissions listed in Required permissions, and add the user to every organization Biggy should see.
(Optional) To authenticate with an API key instead of a username and password, sign in to SL1 12.5.20 or later, open Settings > API Keys. Create an API key for the user you created in step 1 and copy its access key.
Copy the address of the SL1 Database Server, Administration Portal, or All-In-One appliance. (For example, https://sl1.example.com)
In the web app, go to Integrations > Manage Integrations > ScienceLogic SL1 and click + New instance.

Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production ScienceLogic SL1`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your ScienceLogic SL1 environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which organizations, device groups, or collector groups map to which services. This helps Biggy pick the right devices and events.
Authentication method	Select how Biggy authenticates with SL1. The following methods are available: Username & Password: Biggy sends the dedicated SL1 user's name and password as HTTP Basic authentication on read-only REST calls. API Key: Biggy sends an SL1 API key access key, scoped to a read-only user policy, as a bearer token on read-only REST calls. Requires SL1 12.5.20 or later.
SL1 URL	Enter the address of the SL1 Database Server, Administration Portal, or All-In-One appliance copied in step 4. (For example, `https://sl1.example.com`) Biggy calls the REST API under `/api`. Plain `http://` addresses are accepted only when On-premises instance is enabled.
Custom CA Certificate (PEM) (Optional)	If the SL1 appliance's TLS certificate was issued by a private certificate authority, paste the CA certificate (PEM) so Biggy can verify the server TLS certificate.
Username	The name of the dedicated SL1 user you created for Biggy in step 1. This option only appears if you selected Username & Password as the authentication method.
Password	The password for the dedicated SL1 user. Biggy encrypts this value at rest and masks it in the form. This option only appears if you selected Username & Password as the authentication method.
API key access key	Paste the access key copied in step 3. Biggy encrypts this value at rest and masks it in the form. If you paste a value that starts with a `Bearer` prefix, Biggy removes the prefix. This option only appears if you selected API Key as the authentication method.
System Time Zone	Select the system time zone configured in your ScienceLogic SL1 instance. The default value is Coordinated Universal Time (UTC). SL1 writes some dates as local time strings without a time zone, so set this field when the appliance does not run on UTC. This ensures Biggy interprets dates and times correctly.
On-premises instance	Enable this toggle when the ScienceLogic SL1 instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to test the connection before you save.
Click Create Instance.

Selector AI

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

The Biggy Selector AI integration gives Biggy access to correlated events, maintenance windows, and network and infrastructure health from Selector AI.

Biggy connects to your Selector Model Context Protocol (MCP) server with a Selector API key, which Biggy sends as a bearer token.

After you save the connection, Biggy loads the tools exposed by the Selector MCP server and pre-selects the read-only ones. Read-only tools run immediately. Creating, changing, or deleting a maintenance window requires approval, as does any tool not listed in the Selector documentation.

Required permissions

The Selector API key must use a role that has the following permission:

Agent - MCP and ChatOps

API key expiration

By default, a Selector API key is valid for one month from the day you create it. When the key expires, the connection to Biggy stops. Set a longer expiry date when you create the key, and rotate the key before it expires.

Configure the Selector AI integration

To configure the integration:

In Selector, click the profile icon and select My API keys > Add new.
Enter a name for the key (for example, biggy), keep the key Active, and select a role that has the Agent - MCP and ChatOps permission.
In the Key valid until field, set a later expiry date. The default date is one month from today.
Click Add API key and copy the key. Selector displays the key only once, so copy it before you leave the page.
Note your Selector MCP server URL. The URL is your Selector address ending in /mcp/. (For example, https://<your-org>.selector.ai/mcp/)
In the web app, go to Integrations > Manage Integrations > Selector AI and click + New instance.

Populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Selector AI`)
Routing Instructions (optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (optional)	Add notes to help Biggy understand your Chronosphere environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results.
Selector MCP Server URL	Enter the Selector MCP server URL you noted in step 5. (For example, `https://acme.selector.ai/mcp/`) If you leave off the trailing slash, Biggy adds it.
Bearer Token	The Selector API key copied in step 4. Paste the key without the `Bearer` prefix. Biggy sends the key to Selector as a bearer token.
Custom Headers	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the Selector AI instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Selector AI is established. Verify Connection lists the tools the Selector MCP server exposes and calls the echo tool.
Click Create Instance.
In the Allowed tools and approvals section, review the tools Biggy loaded from the Selector MCP server. Biggy pre-selects the read-only tools and gates write and execution tools behind approval. Keep the read-only tools Biggy pre-selects.
Biggy calls no tool on the Selector MCP server until at least one tool is allowed.

Sensu Go

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

Use the Biggy Sensu Go integration to give the agent read-only access to Sensu Go events, entities, checks, handlers, silences, and namespaces during an investigation.

The agent uses the backend REST API to look up the events and entities behind an incident, review check definitions and results, and inspect handler and silence settings.

Read-only access

Biggy only reads from Sensu Go. It never runs a check, resolves an event, or creates, edits, or deletes a silence.

Required Permissions

In Sensu Go, ensure the following are in place before you configure the integration in the web app:

Sensu Go backend: A Sensu Go 6.x backend with its REST API reachable directly over HTTPS or through a Biggy relay client. The default API port is 8080; a reverse proxy can expose a different port.
Read-only user: A dedicated user with read-only permissions. Sensu’s built-in view cluster role grants get and list access. Administrator permissions are not required.
API key: An API key for that user.

Configure Sensu Go

Complete the following steps in Sensu Go:

Using sensuctl configured with an administrator account, create a dedicated user. Replace <password> with a strong password.
```
sensuctl user create biggy --password='<password>'
```
Grant read-only access across namespaces by binding the user to the built-in view cluster role.
```
sensuctl cluster-role-binding create biggy-view --cluster-role=view --user=biggy
```
This binding grants read access across all namespaces. If your organization requires access restricted to selected namespaces, have your Sensu administrator configure namespace-scoped read permissions and separate cluster-scoped permission to list namespaces.
As a Sensu cluster administrator, create an API key for the user.
```
sensuctl api-key grant biggy
```
Copy the key when Sensu displays it. The key remains valid until revoked. Biggy connects with this key, not the password of the user.
Note the backend API URL, for example https://sensu.example.com:8080. Do not use the web UI address on port 3000.
If the backend uses a private or self-signed TLS certificate, obtain its CA certificate chain in PEM format.
If the backend is reachable only inside your network, prepare a Biggy relay client.

Configure the integration

In the web app, go to Integrations > Manage Integrations > Sensu Go.
Click New instance.
On the New Sensu Go Integration page, populate the fields described in the following tables.
For a directly reachable backend, click Verify Connection, then click Create Instance.
For a private backend, turn on On-premises instance and click Create Instance. Go to Configuration > Relay Clients, assign the integration to a connected relay client, and return to the integration to click Verify Connection.

General settings

Field	Description
Instance Name	Enter a name for the instance. For example, `Production Sensu Go`.
Routing Instructions	Describe what this instance covers so Biggy can route queries to it. For example, `EU production accounts`. Recommended for the first instance and required for multiple instances.
Agent Notes (Optional)	Describe how namespaces, subscriptions, and check names map to services, and include investigation guidance relevant to your environment.

Connection settings

Field	Description
Sensu Go backend URL	Enter the full backend API URL, including `https://`. For example, `https://sensu.example.com:8080`. Biggy uses the API under `/api/core/v2/`. Do not enter the web UI address on port `3000`.
API key	Paste the API key created for the dedicated user. Biggy removes a pasted `Key` prefix and stores the key encrypted at rest.
Default namespace (Optional)	Enter the namespace to use when a tool request does not specify one. Leave empty to use `default`. Tools can explicitly request another namespace if the user has access to the namespace.
CA Certificate (PEM) (Optional)	Paste the CA certificate chain for a private or self-signed backend TLS certificate. Leave empty for a certificate signed by a trusted public CA.
On-premises instance	Turn on to route requests through a relay client. After saving, assign the integration under Configuration > Relay Clients. Plain `http://` is accepted only when this option is on.

Backend URL handling: If the URL has no explicit port or path, Biggy adds port 8080. For an HTTPS reverse proxy serving the API at the root on port 443, enter https://sensu.example.com:443. Biggy preserves reverse-proxy path prefixes and does not automatically add port 8080 when a path is present.

Verify the connection

When you click Verify Connection, Biggy requests the namespace list from the Sensu backend.

A successful test confirms that Biggy can reach the backend, authenticate with the key, and list namespaces. It does not confirm permission to read every resource used during an investigation.

Sentry

The Biggy Sentry integration gives Biggy access to issues, errors, stack traces, and traces from your Sentry organization.

Biggy connects to the Sentry Model Context Protocol (MCP) server and acts with the permissions of the Sentry user who authorizes the connection. By default, Biggy uses Sentry's hosted MCP server. You can also scope the connection to a single organization or project, or point Biggy at your own MCP endpoint.

Biggy automatically uses the read-only tools the server exposes. Tools that write or execute, such as resolving an issue, wait for approval before Biggy runs them.

Required permissions

To use the integration, you need:

A Sentry user with read access to the projects Biggy should see. Biggy acts with that user's permissions.
The following permissions enabled on the Sentry consent screen when you authorize Biggy:
- Inspect Issues & Events
- Seer

Leave the Triage Issues and Manage Projects & Teams permissions off.

Configure the Sentry integration

To configure the integration:

In Sentry, choose the user that Biggy acts as. Select a user with read access to the projects Biggy should see.
In the web app, go to Integrations > Manage Integrations > Sentry.

In the General and Connection sections, populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Sentry`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and are required for multiple instances.
Agent notes (Optional)	Add notes to help Biggy understand your Sentry environment. We highly recommend configuring this field, as it allows you to enter organization-specific information for more accurate and consistent results. For example, note which Sentry projects and environments matter, your naming conventions, and any investigation playbooks Biggy should follow.
Sentry MCP Server URL (Optional)	Leave blank to use Sentry's hosted server (`https://mcp.sentry.dev/mcp`), or enter your own Streamable HTTP endpoint. To limit Biggy to one organization, enter `https://mcp.sentry.dev/mcp/<org>`. To limit Biggy to one project, enter `https://mcp.sentry.dev/mcp/<org>/<project>`.
Authorization URL (Optional)	The OAuth authorization endpoint of your identity provider. (For example, `https://idp.example.com/oauth/authorize`)
Token URL (Optional)	The OAuth token endpoint of your identity provider. (For example, `https://idp.example.com/oauth/token`)
Client ID (Optional)	Leave blank to let Biggy register itself automatically when the server supports it. If you enter a client ID, Biggy never overwrites it.
Client secret (Optional)	The client secret for your OAuth client. Leave empty for a public client. The value is masked in the form.
Scope (Optional)	Enter the OAuth scopes Biggy should request, separated by spaces.
Client authentication	Select how Biggy proves the client secret to the token endpoint. The following options are available: Secret in request body Secret in basic header None (public client)
Redirect URL	A read-only callback URL generated for your Biggy environment. (For example, `https://<your_biggy_domain>/api/integrations/mcp/oauth/callback`) Click Copy, then register this exact URL with the provider before you authorize.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

Click Create Instance to save the connection. You must save the connection before you can authorize Biggy.
Select Authorize and sign in to Sentry.
On the Sentry consent screen, keep Inspect Issues & Events and Seer enabled, and leave Triage Issues and Manage Projects & Teams off. Then, complete the authorization.
In the Allowed tools and approvals section, review the selected tools. Biggy loads the tools the Sentry server exposes and pre-selects the read-only ones. Writes and executions, such as resolving an issue, wait for approval.
Biggy calls no tool on the Sentry server until at least one tool is allowed. Make sure at least one tool is selected

Site24x7

Use the Biggy Site24x7 integration to give the agent access to Site24x7 monitoring data during an investigation. Biggy connects through a Zoho MCP server that you create, so you control which Site24x7 tools Biggy may use.

The agent can read monitor status, alarms, outages, and reports to investigate an incident. Biggy selects investigation tools by default. You can select additional tools; tools that write require approval before they run.

Approval does not grant additional permissions. Every tool runs with the access of the Site24x7 user who authorized the connection. Use a user with the Read Only role if the integration must remain read-only.

Access Requirements

Access and permissions required in Zoho and Site24x7:

Zoho MCP access: Access to create and configure a Zoho MCP server and add Site24x7 tools.
Site24x7 user: A user with permission to read the monitoring data you want Biggy to investigate. For read-only access, use the Read Only role.
Authorization method: In Zoho, choose Authorization via Connection for the Biggy MCP URL only method, or Authorization on Demand for Sign in with Zoho.

Treat the MCP URL like a password

The MCP URL contains an API key. Treat the entire URL like a password. If you regenerate the key in Zoho, update the URL in Biggy.

Configure Zoho

Complete the following steps in Zoho before you create the instance:

Create a Zoho MCP server: Sign in to the Zoho MCP console for your data center, such as https://mcp.zoho.com or https://mcp.zoho.eu, and create a server for Biggy.
Add the Site24x7 tools: Add Site24x7 and choose the tools Biggy may use. For MCP URL only connection verification, include at least one of getMonitorStatusCount, getCurrentStatus, or listMonitors.
Set the authorization method: For MCP URL only, configure Authorization via Connection and authorize the Site24x7 connection in Zoho. For Sign in with Zoho, configure Authorization on Demand; you complete authorization from the web app.
Copy the MCP URL: Open the Connect tab of the server and copy the full MCP URL, including its API key.

Configure the integration

Go to Configuration > Manage Integrations > Site24x7.
Click Add Instance.
On the New Site24x7 instance page, populate the fields below.
For a directly reachable server using MCP URL only, click Verify Connection, then click Create Instance. For Sign in with Zoho or a private-network connection, follow the additional steps below.
After saving, review the selected tools. Biggy selects investigation reads by default. Select additional tools only if Biggy should use them; tools that write require approval.

General settings

Field	Description
Instance Name	Enter a name for the instance. For example, `Production Site24x7`.
Routing Instructions	Describe what this instance covers so Biggy can route queries to it. For example, `EU production monitoring`. Recommended for one instance; required for multiple instances.
Agent notes	Enter notes that help the Site24x7 agent work with your system. For example, relevant monitor groups, environments, naming conventions, and investigation playbooks.

Connection settings

Field	Description
Site24x7 MCP Server URL	Paste the full MCP URL copied from the Connect tab in Zoho, including its key. Use the HTTPS MCP endpoint, not the Site24x7 web application address. Local `stdio` or npx launches are not supported. Biggy encrypts and masks the saved URL.
Auth method	Select MCP URL only for Zoho Authorization via Connection, or Sign in with Zoho for Authorization on Demand.
Custom Headers	Optionally expand this section and add header-name and value pairs to send with requests to the MCP server. Header values are masked. With Sign in with Zoho, the OAuth bearer token from Biggy takes precedence over a custom `Authorization` header.
On-premises instance	Enable this option when the MCP server requires private-network access through a Biggy relay client. Save the instance before assigning it under Configuration > Relay Clients. HTTPS is also required for these connections.

Connection in web app

Sign in with Zoho

If you select Sign in with Zoho:

Leave Authorization URL, Token URL, and Client ID empty to use automatic discovery and provider-supported client registration. Enter explicit OAuth settings only if your configuration requires them.
Click Create Instance, or Save Instance when editing an existing instance.
Click Authorize and complete the Zoho sign-in flow.

Biggy cannot load tools or make live requests until authorization is complete. Everyone using this integration instance acts with the permissions of the authorizing user.

Private-network connections

If the MCP server requires a relay client:

Enable On-premises instance and click Create Instance.
Go to Configuration > Relay Clients and assign the saved integration instance to a connected relay client.
Return to the integration and click Verify Connection.

Verification is unavailable until the on-premises instance has been saved. The relay provides access to the MCP server endpoint; this option is not needed merely because some monitored systems are private.

Verify the connection

MCP URL only

When you click Verify Connection, Biggy connects to the MCP server, retrieves its available tools, and calls the first available tool in this order:

getMonitorStatusCount
getCurrentStatus
listMonitors

The selected tool is called without arguments. Verification succeeds when the tool returns a successful Site24x7 response.

A successful test displays “The service is reachable.” This confirms that the MCP connection and the selected verification tool work. It does not confirm access to every monitor or every tool used during an investigation.

Sign in with Zoho

For Sign in with Zoho, verification displays “Credentials Accepted”, but the live connection test is deferred. Save the instance, complete Authorize, and make a request to verify the signed-in connection.

“Credentials Accepted” does not mean an end-to-end Site24x7 request has already succeeded.

Troubleshooting

If the connection fails, check the following:

Available tools: For MCP URL only, include getMonitorStatusCount, getCurrentStatus, or listMonitors in the Zoho MCP server.
Authorization: Match the methods in both products: MCP URL only with Authorization via Connection, or Sign in with Zoho with Authorization on Demand. Complete authorization for the selected method.
Permissions: Confirm that the authorizing Site24x7 user can read monitor status and the monitoring data required for investigations.
MCP URL: Copy the current, complete HTTPS endpoint from the Connect tab in Zoho. If you regenerated the key, replace the saved URL in Biggy.
Endpoint type: Use the remote MCP endpoint, not a Site24x7 web address or a local stdio or npx launch.
Private connectivity: If using a relay, confirm that the integration is saved, On-premises instance is enabled, and the instance is assigned to a connected relay client.

SiteScope

The Biggy OpenText SiteScope integration gives Biggy live monitor, group, and target status from your SiteScope server.

Biggy connects to the SiteScope REST API with a dedicated read-only user and reads the status of the monitor groups you grant it access to. Biggy only reads, so no edit, enable, disable, or run permission is needed.

Requirements

To use the integration, you need:

A SiteScope release that exposes the REST API under /SiteScope/api. SOAP-only releases are not supported.
A dedicated SiteScope user with a role that grants View permission on the monitor groups Biggy should investigate. No edit, enable, disable, or run permission is needed.

OpenText Operations Bridge (OBM) is a separate product and is not covered by this integration.

Configure the SiteScope integration

To configure the integration:

In SiteScope, open Preferences and select User Management Preferences. Create a dedicated user for Biggy with a role that grants View on the monitor groups Biggy should investigate.
Populate the following fields in the web app to set up the integration:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production SiteScope`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and are required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your SiteScope environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which groups map to which services or sites, naming conventions, and the monitors that matter most during an incident.
SiteScope URL	Enter the SiteScope server address, including its port. (For example, `https://sitescope.example.com:8080`) Biggy calls the REST API under `/SiteScope/api`. Pasting the `/SiteScope` path also works.
Username	The dedicated read-only user you created in SiteScope for Biggy.
Password	The password for the SiteScope user. Biggy encrypts this value at rest and masks it in the form.
Custom CA Certificate (PEM) (Optional)	If your SiteScope server uses a private or self-signed certificate, paste the CA certificate chain (PEM) so Biggy can verify the server TLS certificate.
System Time Zone	Select the system time zone configured in your SiteScope instance. This ensures dates and times are interpreted correctly.
On-premises instance	Enable this toggle when the SiteScope instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

After entering the connection details, click Verify Connection to confirm that the connection to SiteScope is established.

SolarWinds

The SolarWinds - Biggy integration is used for observability and monitoring.

To configure the SolarWinds integration, populate the following fields:

Field	Description
SolarWinds Query Endpoint	Enter a SolarWinds Information Service (SWIS) URL and port. (for example, `https://your-solarwinds-instance.com:1774`)
Username	Username of the SolarWinds account Biggy should use for API interactions.
Password	Password of the SolarWinds account Biggy should use for API interactions.
Trusted CA Certificate (optional)	If your SolarWinds instance uses a private or self-signed certificate, provide a trusted CA certificate. If not, TLS verification should be disabled.
Deployment Type	Select whether your SolarWinds integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
SolarWinds Agent Notes	Add notes to help Biggy understand your SolarWinds environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, enter explanations of custom fields and when or how they should be used to handle user queries.

Splunk

The Biggy Splunk integration is used for log monitoring.

Configure the following fields to set up the integration:

Field	Description
Authentication Method	Choose how you'd like to authenticate with this integration. The following methods are available: Basic Authentication - authenticate using a Splunk username and password. Bearer Token Authentication - authenticate using a Splunk bearer token.
Splunk Instance URL	Enter the Base URL and Port of the inbound Splunk instance. Note: When configuring Splunk Enterprise (on-prem), you must include port `8089` in the base URL. (For example, `https://<inbound-ip>:8089`)
Credentials	Enter the credentials that allow the integration to authenticate. If you selected the Basic Authentication method, enter the Username and Password of the Splunk account that Biggy should use for API interactions. If you selected the Bearer Token Authentication method, enter a Splunk Bearer Token.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
Deployment Type	Select whether your Splunk integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
Splunk Agent Notes	Add notes to help Biggy understand your Splunk environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

Splunk Observability Cloud

The Biggy Splunk Observability Cloud integration is used for full-stack observability and application performance monitoring (APM).

Connect Splunk Observability Cloud (formerly SignalFx) so Biggy can investigate metrics with SignalFlow analytics, detectors and active alerts, APM services and traces, and infrastructure entities. Distinct from the Splunk integration, which searches logs/events in Splunk Enterprise/Cloud via SPL.

Biggy queries Splunk Observability Cloud when investigating an issue. It does not ingest, copy, or retain Splunk Observability Cloud telemetry in Biggy for long-term storage.

The integration is read-only. Biggy cannot create, modify, or delete Splunk Observability Cloud resources such as detectors, dashboards, access tokens, or notification policies.

To configure the Splunk Observability Cloud integration:

In Splunk Observability Cloud, open Settings > Access Tokens.
Create an organization access token.
Select the API authorization scope.
Assign a read-only role that provides access to the telemetry you want Biggy to investigate.
Store the token securely until you enter it in Biggy.
In Splunk Observability Cloud, go to Settings > My Profile > Organizations to find your realm.
In the web app Splunk Observability Cloud configuration page, enter the Realm and Org Access Token.

Sumo Logic

The Biggy Sumo Logic integration gives Biggy access to log search, alerts, dashboards, and Cloud SIEM insights in Sumo Logic.

Biggy connects to the Sumo Logic Model Context Protocol (MCP) server using a Client Credentials OAuth client associated with a dedicated Sumo Logic service account. The OAuth client uses read-only scopes, so Biggy only reads your Sumo Logic data, never writes.

Required permissions

Grant the OAuth client only the following read-only scopes:

runLogSearch
viewAlerts
viewLibrary
viewFields
viewFieldExtractionRules
viewPartitions
viewCse
cseViewRules

The runLogSearch scope is required. The other scopes enable the alert, dashboard, field, and Cloud SIEM tools.

Roles

The roles assigned to the service account must include every scope you select for the OAuth client.

Configure the Sumo Logic integration

To configure the integration:

In Sumo Logic, go to Administration > Account Security Settings > Service Accounts and create a service account for Biggy.
Assign the service account roles that can read logs, alerts, and dashboards. If your organization uses Cloud SIEM, include a role that can read Cloud SIEM data.
Go to Administration > Account Security Settings > OAuth Clients and click + Add OAuth Client.
Choose the Client Credentials type, select the service account you created in step 1, and select only the scopes listed in Required permissions.
Copy the client ID and client secret.

In the web app Sumo Logic integration page, populate the following fields:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Sumo Logic`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and become required once a second instance exists.
Agent notes (Optional)	Add notes to help Biggy understand your Sumo Logic environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which Sumo Logic projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.
Deployment	Select the Sumo Logic deployment your account is on. (For example, US1 - US East (N. Virginia)) Biggy sets the Sumo Logic MCP Server URL and Token URL for the selected deployment.
Sumo Logic MCP Server URL	The URL of the Sumo Logic MCP server that Biggy connects to. (For example, `https://mcp.sumologic.com/mcp`) Sumo Logic sets this value, and it can't be changed.
Token URL	The OAuth token endpoint for the selected deployment. (For example, `https://service.sumologic.com/oauth2/token`) Sumo Logic sets this value for the selected deployment, and it can't be changed.
Client ID	The client ID of the OAuth client, copied in step 4.
Client authentication	Select how Biggy proves its identity to the token endpoint. The following options are available: Client secret Private key JWT
Authentication	Enter authentication details. If you selected Client Secret, authentication, enter your Client Secret. If you selected Private key JWT authentication, enter your Private key and (optional) Key ID.
Scope (Optional)	Leave this field blank to use the scopes assigned to the OAuth client in Sumo Logic. To request specific scopes, enter them separated by spaces.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
On-premises instance	Enable this toggle when the Sumo Logic instance is only reachable from inside your network. Requests then route through a relay client assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to confirm that the connection to Sumo Logic is established. Verify Connection lists the tools that the OAuth client can use.
Click Create Instance.
After you save the connection, Biggy loads the tools that the Sumo Logic MCP server exposes. In the Allowed tools and approvals section, check that runLogSearch is selected. Biggy calls no tool on the Sumo Logic MCP server until at least one tool is allowed.
Biggy pre-selects the read-only tools. Tools that create or update dashboards, insights, or rules always ask for approval before they run.

ThousandEyes

Configure the ThousandEyes integration for network monitoring, application availability, BGP analysis, and endpoint metrics.

Required permissions

To ensure Biggy has the access it needs to perform necessary functions, either the ThousandEyes Regular User role must be granted, or a custom role containing the following permissions:

Regular User

Instant tests (optional — applies to both connection types)

Account Admin (The ThousandEyes Instant Tests API requires the Account Admin role to create and run instant tests; each run consumes ThousandEyes units. On the REST API connection type, Biggy asks the person to confirm in the chat before any instant test starts.)

API access
View tests
View agents in account group
View alert rules
View alert suppression windows
View BGP monitors
View dashboards
View endpoint agent data
View endpoint agent settings
View endpoint tests
View labels
View connectors and operations
Internet Insights - Catalog settings

To configure the ThousandEyes integration:

Log in to the ThousandEyes dashboard.
Navigate to Account Settings > Users and Roles > Profile > User API Tokens.
Create a new OAuth bearer token and copy it. Tokens are displayed only once, so store it securely. The Basic Auth token in the same section will not authenticate.
In the web app ThousandEyes integration page, populate the following:

Field	Description
Instance Name	Name of the ThousandEyes instance. This name appears in the list within the web app.
Routing Instructions	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes	Add notes to help Biggy understand your ThousandEyes Logs environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results.
Connection Type	Choose how Biggy connects to ThousandEyes. The same API bearer token works for both options: MCP Server (Recommended): ThousandEyes' hosted MCP server (https://api.thousandeyes.com/mcp). The full, evolving tool set served by ThousandEyes. Default for existing instances. MCP offers the fullest capability. ThousandEyes provides its complete, evolving toolset, including anomaly detection, service maps, Cloud Insights, dashboards, and test/alert rule management. REST API: Biggy queries the ThousandEyes v7 REST API directly (https://api.thousandeyes.com). A curated tool set maintained by Biggy; use when the MCP server is unavailable or disabled for your organization. The REST API option covers curated read-only investigation tools (tests, alerts, events, outages, metrics, path visualization, BGP, endpoint agents) plus on-demand instant tests — it cannot do anomaly detection, service maps, or Cloud Insights, and new capabilities arrive only with Biggy releases.
ThousandEyes API Bearer Token	ThousandEyes bearer token copied in step 3.
ThousandEyes URL (optional override)	Optionally, enter a ThousandEyes MCP URL to use as an override.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.
Deployment Type	Select whether your ThousandEyes integration is Cloud or On-Prem. Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents. Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.
ThousandEyes Agent Notes	Add notes to help Biggy understand your ThousandEyes environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables Biggy to provide more accurate and consistent results. For example, if your logs contain a specific field that is used to identify the type of application or service, provide that information here.

VCF Operations

Use the Biggy VCF Operations integration to give Biggy read-only access to VMware alerts, health, and capacity data during an investigation. VCF Operations was formerly Aria Operations, vRealize Operations, and vROps.

The agent can look up the alerts and resources behind an incident, and review health and capacity for the VMs, hosts, and clusters involved.

Read-only access

Biggy only reads from VCF Operations. It never cancels, suspends, or assigns alerts, and it never runs actions.

Required Permissions

In VCF Operations, these permissions are required:

ReadOnly role: A local user, or an authentication-source user, with the built-in ReadOnly role. Give the role access to the objects Biggy should investigate.
REST API access: Under Administration > Rest APIs, grant Read access to APIs.

Prepare VCF Operations

Complete the following steps in VCF Operations before you create the instance:

Create a local user, or pick an authentication-source user, with the built-in ReadOnly role. Go to Administration, then Access Control. Give the role access to the objects Biggy should investigate.
Note the appliance URL. For example, https://vcf-ops.example.com.
Note the username and password. For an Active Directory, LDAP, or vIDM user, also note the authentication source name exactly as listed under Administration > Access Control > Authentication Sources. Leave the authentication source blank for a local user.
Confirm the account can use the REST API. Under Administration > Rest APIs, grant Read access to APIs.
If the appliance certificate was not issued by a public certificate authority, copy the CA certificate chain in PEM format.
If the appliance is not reachable from the internet, prepare a Biggy relay client.

Configure the VCF Operations Integration

Go to Integrations > Manage Integrations > VCF Operations.
Click Add Instance.
In the New VCF Operations Integration page, populate the fields below.
For a directly reachable appliance, click Verify Connection, then click Create Instance.
For a private appliance, turn on On-premises instance and click Create Instance. Open Relay Clients under Integrations, assign the integration to a connected relay client, and return to the integration to click Verify Connection.

General

Field	Description
Instance Name	Enter a name for the instance. For example, `Production VCF Operations`.
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. For example, `EU production accounts`. This field is recommended, and required for multiple instances.
Agent Notes (Optional)	Enter notes that help the VCF Operations agent work with your system. For example, which clusters serve which applications, naming conventions, and the VMs, hosts, or clusters that matter most during an incident.

Connection

Field	Description
Appliance URL	Enter the VCF Operations appliance or load balancer URL. For example, `https://vcf-ops.example.com`. Biggy calls the Suite API under `<URL>/suite-api`. Alternatively, paste the `/suite-api` path, or the console address (`/ui/...`).
Username	Enter the username of the user with the `ReadOnly` role. For example, `biggy-readonly`.
Password	Enter the password for the user. Biggy stores the password encrypted at rest.
Authentication source (Optional)	For an Active Directory, LDAP, or vIDM user, enter the source name exactly as configured under Administration > Access Control > Authentication Sources. Leave this field blank for a local VCF Operations user.
Custom CA Certificate (PEM) (Optional)	Paste the CA certificate chain in PEM format. This field is required only if the appliance certificate was not issued by a public certificate authority.
On-premises instance	Turn on this toggle if the VCF Operations instance is reachable only from inside your network. Requests route through a relay client, which you assign on the Relay Clients page.

On-premises servers

If the appliance is not reachable from the internet, turn on On-premises instance to route requests through a Biggy relay client. Go to Integrations > Relay Clients to assign it.

Verify the Integration

When you click Verify Connection, Biggy acquires a token and reads the product version. A successful test confirms that Biggy can reach the appliance, authenticate, and read the product version. It does not confirm permission to read alerts, health, or capacity data.

If the test fails, check the following:

Rejected login: The username, password, or authentication source is wrong.
403 error: The account cannot use the REST API. Under Administration, then REST APIs, grant Read access to APIs, and check the ReadOnly role and its object scope.
Appliance URL: Use the appliance or load balancer URL, with or without the /suite-api path.
Certificate: Paste the CA certificate chain in Custom CA Certificate (PEM) if the appliance certificate was not issued by a public certificate authority.
Private connectivity: Confirm On-premises instance is on and the saved integration is assigned to a connected relay client.

Wiz

The Biggy Wiz integration brings cloud security issues, affected cloud resources, and Common Vulnerabilities and Exposures (CVE) findings into Biggy.

Biggy connects to the Wiz GraphQL API with a read-only service account and reads only the projects you grant it access to.

Required permissions

Grant the Wiz service account only the following read scopes:

read:issues
read:vulnerabilities
read:resources

No write or admin scopes are needed. If you scope the service account to specific projects, Biggy only sees those projects.

Configure the Wiz integration

To configure the integration:

In the Wiz portal, go to Settings > Access Management > Service Accounts and create a Custom Integration (GraphQL API) service account. Copy the Client ID and Client Secret. The secret is shown only once.
Grant only the read scopes Biggy uses: read:issues, read:vulnerabilities, and read:resources. No write or admin scopes are needed. If you scope the account to specific projects, Biggy only sees those projects.
Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Wiz`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and are required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your Wiz environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which projects map to which applications or environments.
Wiz GraphQL API URL	Your tenant API endpoint, found on the Tenant page under Settings in the Wiz portal. Commercial (`app.wiz.io`), FedRAMP (`app.wiz.us`), and GovCloud (`gov.wiz.io`) hosts are accepted. (For example, `https://api.<region>.app.wiz.io/graphql`)
Wiz OAuth Token URL	The token endpoint for the same Wiz environment as the API URL. Tenants that still authenticate at `https://auth.wiz.io/oauth/token` can keep that URL. (For example, `https://auth.app.wiz.io/oauth/token`)
Client ID	The service account Client ID from Wiz.
Client Secret	The service account Client Secret from Wiz. Biggy encrypts this value at rest and masks it in the form. The secret is shown only once in Wiz, so copy it when you create the service account.
OAuth Audience (Optional)	Leave empty to use `wiz-api`. The value `beyond-api` is applied automatically for the legacy `auth.wiz.io` token host. Set a value only if Wiz support told you to.

After entering the connection details, click Verify Connection to confirm that the connection to Wiz is established.

Zabbix

Use the Biggy Zabbix integration to give the agent access to Zabbix monitoring data during an investigation. Monitoring lookups are read-only.

Biggy connects to the Zabbix JSON-RPC API with a dedicated user, so you control which host groups Biggy can investigate.

Read-only access

Biggy's monitoring, version, and login lookups are read-only. They use only the *.get API methods. No write permissions are needed.

Required Permissions

In Zabbix, confirm the following are in place before you configure the integration:

Zabbix version: Zabbix 6.0 or later. API tokens existed before Zabbix 6.4, but for Zabbix 6.0 LTS Biggy recommends the Username & Password authentication method.
User role: A user role of type User (or higher) with API access set to Enabled.
User group: A user group with Read permission on the host groups Biggy should investigate.

Prepare Zabbix

Complete the following steps in Zabbix before you create the instance:

Create a dedicated Biggy user. Go to Users > Users > Create user. Give the user a User-type role with API access enabled. Grant its user group Read permission on the host groups Biggy should be able to investigate.
Choose how Biggy authenticates. For Zabbix 6.0 LTS, Biggy recommends Username & Password, so note the username and password of the dedicated user.
To use an API token, create one for the user, then set an appropriate expiry, and copy the token value
- While signed in as that user, open User settings, then select API tokens.
- As an admin, open Users, then select API tokens and choose the Biggy user.
Note the Zabbix frontend URL, the address used to open the Zabbix UI. For example, https://zabbix.example.com/zabbix. Biggy calls the JSON-RPC API at <URL>/api_jsonrpc.php.
If needed, note the optional settings:
- CA certificate: Copy the CA certificate chain in PEM format if the Zabbix server uses a private or self-signed certificate.
- Time zone: Note the system time zone configured in your Zabbix instance.
If the Zabbix server is not reachable from the internet, prepare a Biggy relay client.

Configure the Zabbix Integration

Go to Integrations > Manage Integrations > Zabbix.
For the first Zabbix instance, the new instance form opens directly. For each additional instance, click Add Instance.
On the new instance page, populate the fields described in the following tables.
For a directly reachable server, click Verify Connection, then click Create Instance.
For a private server, turn on On-premises instance and click Create Instance. Open Relay Clients under Integrations, assign the instance to a connected relay client, and return to the integration to click Verify Connection.
Enable the instance. New instances start disabled.

General

Field	Description
Instance Name	Enter a name for the instance. For example, `Production Zabbix`.
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. For example, `EU production accounts`. This field is recommended, and required for multiple instances.
Agent Notes (Optional)	Enter schema nuances or tips so Biggy can better interact with your Zabbix instance. For example, host group naming conventions and which host groups matter most during an incident.

Connection

Field	Description
Authentication method	Select how Biggy authenticates with Zabbix: API Token or Username & Password. For Zabbix 6.0 LTS, Biggy recommends Username & Password. The default is API Token.
Zabbix URL	Enter your Zabbix frontend URL, the address you open the Zabbix UI at. For example, `https://zabbix.example.com/zabbix`. Biggy calls the JSON-RPC API at `<URL>/api_jsonrpc.php`.
Custom CA Certificate (PEM) (Optional)	Paste the CA certificate chain in PEM format. This field is required only if the Zabbix server uses a private or self-signed certificate.
API Token	Enter the Zabbix API token you copied. This field applies when the Authentication method is API Token.
Username	Enter the username of the dedicated Biggy user. This field applies when the Authentication method is Username & Password.
Password	Enter the password of the dedicated Biggy user. This field applies when the Authentication method is Username & Password.
System Time Zone	Select the system time zone configured in your Zabbix instance. Biggy gives this time zone to the agent as context. It does not convert timestamps. The default is Coordinated Universal Time (UTC).
On-premises instance	Turn on this toggle if the Zabbix instance is reachable only from inside your network. Requests route through a relay client, which you assign on the Relay Clients page. For more information, see Relay Clients.

On-premises servers

If the Zabbix server is not reachable from the internet, turn on On-premises instance to route requests through a Biggy relay client. Go to Integrations > Relay Clients to assign it.

Zabbix connection in web app

Verify the Integration

When you click Verify Connection, Biggy requests the Zabbix API version, authenticates, and attempts to read one host. An empty result still passes.

A successful test confirms that Biggy can reach the API and authenticate. It does not confirm Read permission on the host groups Biggy should investigate.

If the test fails, check the following:

Zabbix URL: Use the address you open the Zabbix UI at, including any path such as /zabbix. Biggy adds /api_jsonrpc.php.
Authentication method: For Zabbix 6.0 LTS, Biggy recommends Username & Password. Confirm the Authentication method matches the credentials you entered.
API token or login: Confirm the token belongs to the Biggy user and has not expired, or that the username and password are correct.
Permissions: Confirm the user role is of type User or higher with API access enabled. Confirm the user group has Read permission on the host groups Biggy should investigate.
Certificate: Paste the CA certificate chain in Custom CA Certificate (PEM) if the server uses a private or self-signed certificate.
Private connectivity: For a server not reachable from the internet, confirm On-premises instance is on and a connected relay client is assigned.

Zscaler ZDX

The Biggy Zscaler ZDX integration lets Biggy view digital-experience alerts, app scores, users, devices, and Cloud Path data from Zscaler Digital Experience (ZDX).

Biggy connects to the ZDX API with an API key and reads within the tenant's ZDX license scope.

Collection delay

ZDX telemetry arrives with an estimated 20-minute collection delay, and most reports cover 2-hour windows. Biggy states this on every answer rather than presenting the data as live.

Prerequisites

To use the integration, you need:

A ZDX subscription with API access. The API key inherits the tenant's ZDX license scope.
A ZDX API Key ID and Key Secret, created under Administration > Authentication > API Key Management.

ZDX enforces a rate limit of 5 requests per second on every tier. Biggy runs long lookbacks sequentially to stay within it.

Configure the Zscaler ZDX integration

To configure the integration:

Create an API key in the ZDX Admin Portal. Go to Administration > Authentication > API Key Management and create an API key, or download the key file. Copy the Key ID and Key Secret. The secret is shown only once.
Populate the following fields in the web app:

Field	Description
Instance Name	A human-readable name to identify this instance in the list. (For example, `Production Zscaler ZDX`)
Routing Instructions (Optional)	Describe what this instance covers so Biggy can route queries to it. (For example, `EU production accounts`) Routing instructions are recommended, and required for multiple instances.
Agent Notes (Optional)	Add notes to help Biggy understand your ZDX environment. We highly recommend configuring this field, as it allows you to enter organization-specific information that enables more accurate and consistent results. For example, note which ZDX applications map to which business services, department or location naming, and the ZDX Score thresholds that matter to you.
ZDX API URL	The ZDX API base for your Zscaler cloud, including the version your tenant is provisioned for. Your cloud is the one in your Admin Portal address, `admin.<cloud>.net`. (For example, `https://api.zdxcloud.net/v1`, or `/v2`)
API Key ID	The ZDX API Key ID created in the Admin Portal.
API Key Secret	The ZDX API Key Secret. Biggy encrypts this value at rest and masks it in the form. The secret is shown only once in the Admin Portal, so copy it when you create the key.
Custom Headers (Optional)	Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

After entering the connection details, click Verify Connection to confirm that the connection to Zscaler ZDX is established.

In this section: