Access keys

Create and revoke integration keys with read, write and project scopes.

Last updated: 10 November 2026

Permission model

An access key belongs to an organisation user. The user's current role, organisation state, project membership, module permissions and region permissions are checked again on every request. A key does not extend user permissions. A Viewer can create read-only keys; an organisation-independent super administrator cannot create a key through this workflow.

Key management under /api/anahtarlar uses a user session. The key itself is used in v1 API and OGC requests.

Creating a key

1. Sign in to a user session.
2. Choose a meaningful ad, the required kapsam and project selection.
3. Send POST /api/anahtarlar.
4. Store the sir from the 201 response. It is shown only when the key is created and is not returned by listing requests.
5. Check the key identity with GET /api/v1/me.

{
  "ad": "Envanter okuma",
  "kapsam": ["oku"],
  "proje_ids": [123],
  "bitis_at": null
}

123 is an example project identifier. kapsam can only be ["oku"] or ["oku", "yaz"]. proje_ids: null means general scope restricted to projects the user can access; an empty array means no project access. Project identifiers must be unique.

bitis_at may be omitted. When provided, it must be a future date-time with a time zone and no more than 730 days ahead. Names are 1–64 characters long; each user can create up to 20 active keys.

Listing and revoking

The list includes identifier, name, onek, scope, project identifiers, expiry, last-use and revocation times. It excludes the complete secret and its digest. Users can revoke their own keys; organisation administrators can revoke keys in the same organisation.

To change scope, create a new key with the appropriate scope, migrate the integration to it and revoke the old key. A key stops working when its user or organisation becomes inactive or when it expires. Do not assume an old key can be used again.