API Credentials and Authentication Terms

A practical field guide from Automation Ace.

A Glossary for API Credentials and Authentication

API documentation often assumes everyone already understands the difference between an API key, a secret key, a bearer token, a JWT, and an OAuth refresh token. In real automation work, those labels matter because each credential has a different risk level, lifetime, storage requirement, and failure mode.

Use this guide as a translation layer when you are connecting Zapier, Make, Airtable, CRMs, payment processors, internal tools, or custom code to an API. For a broader implementation walkthrough, read API authentication for automation. For planning custom endpoints and webhook systems, see webhook and API integration consulting.

The Big Distinction: Public Identifiers vs. Secrets

Some values only identify an app, project, tenant, or user. Others prove access and must be treated like passwords. A client ID, public key, or project key may be safe to show in a browser if the provider says so. A client secret, private key, refresh token, webhook secret, or service account key should never be exposed in client-side code, screenshots, task history, or logs.

If a credential can create, update, delete, impersonate, decrypt, sign, or mint new tokens, store it as a secret and design a rotation plan before the automation goes live.

Keys: Static Credentials and Identifiers

API key

A static identifier used to authorize API requests. Some API keys are low-risk read-only identifiers, but many act like passwords and should be stored securely.

Secret key

A confidential API key with elevated, write, billing, or administrative access. Secret keys belong in a secure connection store or environment variable, never in frontend code.

Public key

A non-secret identifier that can often be exposed in client-side code. Public keys are commonly paired with private keys for cryptography or publishable API access.

Private key

A confidential cryptographic key used for signing or decryption. Treat private keys as high-impact secrets because compromise can allow impersonation or data exposure.

Service account key

A credential assigned to an application, server, or machine identity instead of a human user. Use it for backend automations, limit its permissions, and rotate it when maintainers change.

Subscription, project, application, tenant, and license keys

Provider-specific labels for credentials or identifiers scoped to a product plan, project, app, workspace, customer tenant, or software license. Read the provider's docs carefully: some are safe identifiers, while others grant real access.

Tokens: Short-Lived, Long-Lived, User, Bot, and Machine Access

Access token

A credential granting access to specific resources or actions. Access tokens are often short-lived and scoped to a user, app, workspace, or service account.

Bearer token

An access token sent in the HTTP header format Authorization: Bearer <token>. Whoever has the token can use it, so protect it from logs and browser exposure.

OAuth token

A token issued through an OAuth authorization flow. It usually represents a user's consent for an app to access selected resources.

Refresh token

A long-lived token used to obtain a new access token. Refresh tokens are more sensitive than short-lived access tokens because they can extend access over time.

ID token

An OpenID Connect token containing authenticated user identity claims. ID tokens answer “who is this user?” and are not a general substitute for API access tokens.

JWT

A signed token containing structured claims. JWTs are often used as access tokens or ID tokens, but a token being a JWT does not automatically mean it is safe to decode and trust without validating its signature, issuer, audience, and expiry.

Session token

A temporary credential tied to a login session. It is usually managed by a web app or authentication service and should expire when the session ends.

Personal access token (PAT)

A user-generated token used instead of a password, commonly for developer platforms and APIs. PATs often inherit user permissions, so create dedicated automation users when possible.

Bot, app, user, workspace, machine, and device tokens

Tokens named for the identity they represent or the scope where they operate. Before using one in an automation, confirm whether actions will appear as a bot, installed app, human user, server process, device, or workspace-level integration.

OAuth and Authorization Flow Terms

Client ID

The public identifier for an OAuth application. It tells the provider which app is requesting access.

Client secret

The confidential password for an OAuth application. Keep it on the server side or in the platform's secure auth configuration.

Consumer key and consumer secret

OAuth 1.0 terms similar to client ID and client secret.

Request token

A temporary OAuth 1.0 credential used during authorization before the final access token is issued.

Authorization code

A short-lived OAuth code returned after user consent and exchanged for tokens. It is not the final credential and should be used only once.

API token, authentication token, authorization token, and security token

Broad labels that vendors use inconsistently. When you see one of these terms, check whether the token proves identity, grants permissions, expires, refreshes, or needs a signature.

One-Time, Temporary, and Verification Credentials

One-time token

A credential valid for a single use, such as a magic link, verification link, or sensitive action approval.

Temporary credentials

A short-lived key, secret, and token combination, often used by cloud providers for assumed roles or limited-time machine access.

Registration, invite, reset, and verification tokens

Purpose-specific tokens used to register an app or device, accept an invitation, reset a password, or verify an email, phone number, or request. Keep them short-lived and single-purpose.

CSRF token

A token used to prevent cross-site request forgery by proving that a browser request came from the expected page or session.

Nonce

A one-time random value used to prevent replay attacks. Nonces are common in signed requests, OAuth, OpenID Connect, and webhook verification.

Signed, Opaque, Webhook, and Cryptographic Secrets

Signed token

A token whose integrity is verified with a digital signature. Signed tokens can still be dangerous if the receiving system skips validation.

Opaque token

A random token whose contents cannot be interpreted by the client. The API server or authorization server must look it up or introspect it.

Webhook secret, signing secret, HMAC secret, and shared secret

Confidential values known by both systems and used to verify request signatures. These secrets help prove a webhook or API request was created by the expected sender and was not modified in transit.

Encryption key

A key used to encrypt or decrypt data. Encryption keys protect confidentiality and require stricter handling than ordinary app identifiers.

SSH key

A public/private key pair used for secure server authentication, Git access, and infrastructure automation.

Certificate and mTLS certificate

Digitally signed credentials used to establish identity and trust. In mutual TLS, a client certificate authenticates the calling application or machine to the server.

Passkey

A public-key credential used for passwordless authentication. Passkeys are designed for phishing resistance because the private credential stays protected by the user's device or password manager.

How to Decide Where a Credential Belongs

• Frontend-safe: Only expose values explicitly described as public, publishable, or client-side safe by the provider.
• Connection store: Put API keys, OAuth tokens, PATs, and service credentials in Zapier, Make, or the app platform's built-in secure connection manager.
• Environment variables: Use encrypted environment variables for custom code, serverless functions, and backend scripts.
• Never in logs: Redact bearer tokens, refresh tokens, private keys, client secrets, webhook secrets, and authorization headers before saving run history or sharing screenshots.
• Rotate by scope: Create separate credentials for development, testing, and production so rotation and revocation do not break every workflow at once.

Practical Rule for Automation Builders

When an API asks for a credential, do not copy it into the first field that seems to work. Identify what the credential represents, what permissions it grants, how long it lives, how it expires, and where it can safely be stored. That small pause prevents the most common automation security problems: leaked keys, stale OAuth connections, over-permissioned service accounts, and webhook endpoints that accept spoofed data.