API keys

Long-lived credentials for applications — what exists today, and the alternatives where they don't yet.

Not verified yet

API keys are the right credential for applications calling Norcube: fixed secrets your service holds, not user-bound tokens that expire weekly.

Today

  • LangSync has API keys — organization-scoped, read-only against its Public API. Create and manage them in LangSyncAPI keys; full docs at LangSync → API keys.
  • DomainRadar shows an API Keys page marked "coming soon" — its API currently accepts session tokens only.
  • Backup and PromptHub have no API keys yet.

For products without keys, the workable pattern is a service-account user: a dedicated account invited to your org with a Viewer/Admin role, whose refresh token your integration stores and exchanges for access tokens via the OAuth2 refresh flow. Mind the 7-day refresh-token lifetime — the integration must refresh at least weekly, and persist rotated refresh tokens.

Cross-product API keys and personal access tokens are roadmap items, not shipped features.

Usage shape (LangSync)

Authorization: Apikey <your-api-key>

Bearer is also accepted with the same key value.

Best practices

  • One key per application — rotation and revocation stay surgical.
  • Store keys in a secret manager (or your CI's secret store). Never in a repository.
  • Rotate deliberately: create the new key, deploy it, watch the old key's Last used at stop moving, then revoke.
  • Revoke immediately on leak — revocation is instant; the next request with the revoked key gets 401.

Behaviour and edge cases

  • Keys are organization-scoped — a LangSync key reads every namespace in the org; there are no per-resource scopes.
  • The full value is shown exactly once at creation; afterwards only a preview. Lost value = new key.
  • Keys don't expire on their own and revoked keys can't be restored.

On this page