Nembl
Admin Guide
Identity & Access
API Keys

API Keys

API Keys let external systems and scripts authenticate to the Nembl REST API as a programmatic identity. Use them for: CI/CD pipelines submitting requests, integrations posting data, automation scripts, and webhook senders that need server-to-server auth.

Open from Admin → IAM → API Keys.

For human session auth (sign-in flows), see Authentication.

What an API Key represents

An API Key is a credential bound to a service principal in your Company. Calls authenticated with the key:

  • Run as the service principal (audited under that name)
  • Are scoped to the Roles you grant the principal
  • Respect the same Policies and tenant scope as a User would

Issuing a key

  1. Click New API Key
  2. Name it after where it will be used (e.g. github-actions-prod, acme-zapier-integration)
  3. Pick the Roles the key holds (usually a service-only Role like api-request-submitter, not an admin Role)
  4. Optionally set:
    • Expires at — auto-expiry date (leave blank for "never")
    • IP allow-list — comma-separated CIDRs that may use this key
  5. Click Create
⚠️

Copy the key now. Nembl shows the secret value once at creation time. Store it in your secrets manager (1Password, vault, etc.) immediately — Nembl only persists the hash, so a lost key has to be regenerated.

Using a key

Pass the key in the Authorization header:

Authorization: Bearer nbl_<key-id>_<secret>

Every request is rate-limited per-key (defaults: 60/min, 5000/hour; configurable per key for higher-traffic integrations).

Listing & rotating

The list view shows for each key:

  • Name + creator + created date
  • Last used — timestamp of the most recent request
  • Status — ACTIVE / EXPIRED / REVOKED
  • Roles held
  • IP restrictions if any

Rotation

Click Rotate on a key to generate a new secret while keeping the same name and Role bindings. The old secret continues to work for 24 hours (a grace window so you can update consuming systems without downtime), then is revoked.

Revocation

Click Revoke to immediately disable the key. No grace period. Use this when a key is leaked or a former integration is decommissioned.

Best practices

  • One key per consumer. Don't reuse the same key across two integrations — revoking one means breaking the other.
  • Least-privilege Roles. A key that only needs to submit requests gets api-request-submitter, not admin.
  • Rotate quarterly. Set a calendar reminder. Use the 24-hour grace window to make rotation zero-downtime.
  • Restrict by IP when the consumer has a stable egress IP (most CI runners and on-prem integrations do).
  • Set expiry for one-shot keys (e.g. a contractor's data export script that ships in two weeks).
  • Treat keys like passwords. Never check them into source control; never paste them into chat. If a key is exposed (committed to a public repo, posted in a screenshot, etc.), revoke it immediately and issue a new one.

Related

TagsCompany Settings