# Changelog - Apr 22, 2026

**Documentation:** https://docs.composio.dev/docs/changelog/2026/04/22

## Credential Redaction for Composio-Managed Auth Configs and Connections

Composio-managed auth configs and their connections now redact sensitive fields in API responses. Customer-owned auth configs mask every credential field except the public OAuth identifiers.

Two related security changes are rolling out together:

1. **Connections on Composio-managed auth configs** now always redact `access_token`, `refresh_token`, and the `Authorization` header in `connected-accounts` responses — independent of your project's `mask_secret_keys_in_connected_account` flag.
2. **Auth-config GET responses** now redact (for Composio-managed) or mask (for customer-owned) every sensitive credential field.

Auth-config credential redaction is **not controlled by `mask_secret_keys_in_connected_account`**. That project flag only applies to runtime connected-account credentials (access tokens, refresh tokens, and the like). Auth-config credentials are developer-owned static fields — `client_id`, `client_secret`, `developer_token`, etc. — and are always redacted or masked regardless of the `mask_secret_keys_in_connected_account` project flag.

**Most integrations need no changes.**

* Tool execution through the SDK, Tool Router, and MCP is unchanged. Composio uses the unredacted values server-side.
* Connections on customer-owned auth configs continue to follow your project's `mask_secret_keys_in_connected_account` setting for runtime tokens.

## What is a Composio-managed auth config?

When you connect a user through a toolkit's default integration — for example, Gmail or Slack without registering your own OAuth application — Composio uses an OAuth application it owns and shares across every team on that default. Tokens the provider issues are bound to that shared Composio-owned client.

You can identify a Composio-managed auth config or connection by `is_composio_managed: true` on the auth-config or connected-account resource.

## 1. Connected-account tokens

Access tokens, refresh tokens, and all header and query-parameter values are now replaced with the literal string `"REDACTED"` for Composio-managed connections. No prefix, no suffix — nothing that reveals the underlying value.

Before, with `mask_secret_keys_in_connected_account: false` on a Composio-managed Gmail connection:

```json
{
  "state": {
    "val": {
      "access_token": "ya29.a0ARrdaM9...full token...",
      "refresh_token": "1//04...full token..."
    }
  },
  "data": {
    "headers": {
      "Authorization": "Bearer ya29.a0ARrdaM9...full token..."
    }
  }
}
```

After:

```json
{
  "state": {
    "val": {
      "access_token": "REDACTED",
      "refresh_token": "REDACTED"
    }
  },
  "data": {
    "headers": {
      "Authorization": "REDACTED"
    }
  }
}
```

Connections on customer-owned auth configs are unaffected — token visibility follows your existing `mask_secret_keys_in_connected_account` setting (`xxxx...` truncation when enabled, raw passthrough when disabled).

If you were reading Composio-managed access or refresh tokens from these responses — typically because you use Composio for OAuth and then call the provider's APIs yourself — register your own OAuth application with the provider and [create a custom auth config](/reference/api-reference/auth-configs/postAuthConfigs) against those credentials. Tokens issued against an OAuth application you own belong to you and are returned in full (subject to `mask_secret_keys_in_connected_account`).

## 2. Auth-config credentials

`GET /api/v3/auth_configs` and `GET /api/v3/auth_configs/{id}` no longer return sensitive credentials in a recoverable form.

* **Composio-managed auth configs** — every credential field is redacted.
* **Customer-owned auth configs** — public OAuth identifiers (`client_id`, `consumer_key`) still pass through so you can debug OAuth flows. Every other credential field is obfuscated.

If your code reads a secret — for example `client_secret` or `developer_token` — out of these responses, you will need to keep that value alongside the code that created the auth config (typically in your own secret manager at upload time).

## Why this change

A single OAuth application backs every team on a Composio-managed default integration, and the tokens and client secrets bound to it are shared. If a provider throttles, restricts, or suspends that app in response to misuse of one of its credentials, the integration becomes unavailable for every team on the default at once. Redacting the values keeps them out of API responses; Composio still uses them server-side, so tool execution is unchanged.

For customer-owned auth configs, masking a freshly re-read `client_secret` or `developer_token` limits the blast radius of a compromised project API key without breaking your ability to identify which credential was uploaded.

## Affected endpoints

Connected accounts:

* [`GET /api/v3/connected_accounts/{id}`](/reference/api-reference/connected-accounts/getConnectedAccountsByNanoid)
* [`GET /api/v3/connected_accounts`](/reference/api-reference/connected-accounts/getConnectedAccounts)
* [`POST /api/v3/connected_accounts`](/reference/api-reference/connected-accounts/postConnectedAccounts)
* Webhook payloads that include connection credentials

Auth configs:

* [`GET /api/v3/auth_configs/{id}`](/reference/api-reference/auth-configs/getAuthConfigsByNanoid)
* [`GET /api/v3/auth_configs`](/reference/api-reference/auth-configs/getAuthConfigs)

> If your integration relies on reading `access_token`, `refresh_token`, `client_secret`, or `developer_token` from Composio API responses, you will need to act. All other integrations continue to work as before.

---