# General Translation Platform: API keys
URL: https://generaltranslation.com/en-US/docs/platform/dashboard/reference/api-keys.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Create and manage project and Organization API keys for apps, local development, and automation. Reference for API keys.

API keys authenticate your apps, CLI, and automation with General Translation. Use the narrowest key scope that fits the workflow.

## Key scopes [#key-scopes]

General Translation supports two API key scopes:

- **Organization keys** for Organization-level automation. Use them for org-level automation or workflows that need to operate across projects in the Organization.
- **Project keys** for a single project. Use them for deployed apps, local development, previews, and project-scoped tooling.

Organization keys and project keys have different creation flows. Project keys are created as production or development keys. Organization keys use a permission selector.

## Create Organization keys [#create-organization-keys]

Create Organization keys from **Organization > Developer > API Keys**. Organization keys use the `gtx-org-` prefix and can be configured with a custom permission set.

Permissions are configured per resource. `Write` includes `Read`.

| Resource                | Read                                  | Write or enabled                                      |
| ----------------------- | ------------------------------------- | ----------------------------------------------------- |
| **Project creation**    | Not applicable                        | Create new projects in the Organization               |
| **Project API keys**    | View API keys for projects             | View and create project API keys                      |
| **Files**               | Read project files and translations   | Upload source content and write translated files      |
| **Context**             | Read project and Organization context | Manage Context Groups, Glossary, and Custom Prompts    |
| **Runtime translation** | Not applicable                        | Translate content on demand                           |
| **Translation queue**   | Not applicable                        | Queue file translation jobs for background processing |
| **Project settings**    | Not applicable                        | Update project settings such as the default locale and CDN delivery |

Enable **Project creation** for automation that calls the [Create a project](/docs/platform/openapi/reference/project/create-project) endpoint. Also enable **Project settings** when that automation creates projects with CDN delivery enabled. Grant each key only the permissions it needs.

Set **Project API keys** to **Write** for automation that calls [Create a project API Key](/docs/platform/openapi/reference/project/create-api-key). The endpoint accepts a name and an optional production or development key type; it does not accept custom permissions. The created key receives the defaults for its type, limited to the project permissions held by the request identity. The request identity can be an Organization key or an OAuth user access token; project keys cannot hold the required `project:api_keys:write` permission.

## Create project keys [#create-project-keys]

Create project keys from **Project > API Keys**. Copy the full key immediately and store it in environment variables, a secrets manager, or another secure store.

- **Production keys** start with `gtx-api-`.
  - Use them for file uploads, translation jobs, and production automation. Keys created in the Dashboard have the default project permissions; an Organization API-created key may have fewer delegated permissions.
- **Development keys** start with `gtx-dev-`.
  - Use them for on-demand translation during local development. Their default permission is runtime translation; production-only endpoints reject them.
  - Do not use development keys in production.

In most SDK and CLI workflows, use the key with your project ID:

```bash
GT_API_KEY=gtx-api-...
GT_PROJECT_ID=...
```
## Manage keys [#manage-keys]

Use descriptive names so keys are easy to identify later.

Open the key list for the project or Organization to review existing keys. The key list shows:

- **Name** and **Key**, including a truncated key for identification
- **Permissions**, for Organization keys
- **Created**, when the key was generated
- **Last Used**, when the key was last used

With permission to manage keys, use **Edit key** to rename a key or update an Organization key's permissions, and **Delete** to revoke it. The full secret is shown only when the key is created.

Revoke keys that are no longer used, and create replacements when rotating credentials.

## Security practices [#security-practices]

- Never commit keys to source control.
- Store keys in environment variables or a secrets manager.
- Use separate keys for development, staging, and production.
- Rotate keys periodically.
- Revoke unused keys.
- Prefer the narrowest scope that works for the integration.

## Sitemap

See the full [sitemap](https://generaltranslation.com/sitemap.md) for all pages.