> For the complete documentation index, see [llms.txt](https://docs.datalogz.io/guides/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datalogz.io/guides/organizational-setup/connected-apps-oauth-clients.md).

# Connected apps (OAuth clients)

## Connected apps (OAuth clients)

OAuth clients allow external applications to connect securely to Datalogz without using a user’s password. Currently, OAuth clients provide access to the Datalogz MCP server.

Each OAuth client belongs to your organization. MCP clients can access data from all active connectors in the organization; access is not limited by team membership.

You need the **Account Settings Admin**, **BI Admin**, or **System Admin** role to manage OAuth clients.

### Client types

| Type                    | Use it for                                                                    | Credentials                                  |
| ----------------------- | ----------------------------------------------------------------------------- | -------------------------------------------- |
| **Machine credentials** | Services, scripts, and unattended automations                                 | Client ID and client secret                  |
| **Interactive PKCE**    | Applications where a user signs in and approves access, such as an MCP client | Client ID and redirect URI; no client secret |

Some MCP applications register automatically. After an administrator approves the connection, the client appears on this page.

Create an Interactive PKCE client manually only when the application asks you to provide a client ID and redirect URI.

### Create an OAuth client

1. In Datalogz, open **Organization → OAuth Clients**.
2. Select **New OAuth Client**.
3. Enter a recognizable name, such as `Analytics assistant — Production`.
4. Select the client type.
5. For an **Interactive PKCE** client, enter the exact redirect URI supplied by the external application.
6. Select **Create**.

Redirect URIs must:

* Match the external application’s callback URI exactly.
* Use HTTPS, except for local applications using `localhost`.
* Not contain wildcards.
* Be added individually when the application uses more than one callback URI.

#### Machine credentials

After creating a Machine credentials client, copy the client ID and client secret immediately.

The secret is shown only once and cannot be recovered later. Store it in a password manager or secrets-management system. Do not place it in source code, documentation, or chat messages.

#### Interactive PKCE

Interactive PKCE clients do not have a client secret. Copy the generated client ID into the external application when requested.

When connecting, the user is redirected to Datalogz to sign in and approve access.

### Replace credentials

**OAuth client credentials cannot be edited or regenerated.**

To replace a client:

1. Create a new OAuth client.
2. Update the external application with the new credentials.
3. Confirm that the application can connect.
4. Delete the old client.

### Delete an OAuth client

Select the delete action next to the client you want to remove.

Deleting a client is permanent. The application immediately loses access, and its existing tokens and interactive authorizations can no longer be used. Other OAuth clients are not affected.

Delete clients that are unused, belong to retired applications, or may have been compromised.

### Recommended practices

* Create a separate client for each application and environment.
* Use names that clearly identify the application and owner.
* Treat a machine client secret like a password.
* Register only redirect URIs you trust.
* Delete clients as soon as they are no longer needed.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.datalogz.io/guides/organizational-setup/connected-apps-oauth-clients.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.