# Data Access Points and keys

Last updated: 2026-10-11

A Data Access Point is a process identity for an unattended script or an application's backend. It holds grants to selected Approved Requests. It is separate from the person viewing a Hosted Application.

This page covers a key-based Data Access Point that a person creates for a process.

## Create and grant access

As a Project Administrator, open **Data Access Points** in the Project. Its page path is:

```text
/projects/<projectId>/data-access-points
```

Create a Data Access Point, give it a name, and select the approved Requests it needs. Creation requires a nonempty selection. Review any confirmation about sensitive data before granting access.

Save the key when it is created. Keys start with `ekai-` and are shown only at creation or rotation; they cannot be revealed later. Keep the key in the process's secret store. Do not place it in browser JavaScript or application files.

An Administrator's agent can use `list_data_access_points` to inspect grants. That listing does not reveal keys or prove that a listed key still authenticates. Enforcement can revoke a key while leaving its Data Access Point and grants listed.

## Use the key

Send the key as a Bearer credential in the `Authorization` header:

```text
Authorization: Bearer <Data Access Point key>
```

Use the Project's Region and identifier for either interface:

```text
https://<region>.ekaya.ai/mcp/<projectId>
https://<region>.ekaya.ai/api/data/v1/projects/<projectId>
```

The HTTP catalog shows the approved Requests this identity can call. See [Call an approved Request](/docs/call-an-approved-request/) for examples.

## Rotate or remove access

Use **Rotate key** on the Data Access Points page to replace a key. Save the replacement and update the process's secret store. The old key no longer authenticates subsequent calls.

Edit the Data Access Point's Request selection to change its grants. To remove a manually created Data Access Point and revoke its key, delete it. A Data Access Point managed by a connection is removed with its owning datasource or connection instead.

## Keep process and person access separate

App access and Request grants are separate. A Hosted Application uses its signed-in viewer's Role and permitted Requests; a process key is not a substitute for that person's identity.

A Request bound to a verified person cannot be granted to a Data Access Point. A Data Access Point's subject binding is fixed at creation; changing that binding requires a new Data Access Point.