Automation Blog

API Authentication for Automation

A practical overview of API keys, OAuth, bearer tokens, refresh flows, and credential handling in automation projects.

API IntegrationAuthenticationSecurity

By Troy Tessalone · · 5 minutes

Automation Guide

A practical field guide from Automation Ace.

API Authentication for Automation Builders

Every API integration fails or gets misconfigured at the authentication layer first. Understanding the difference between API keys, OAuth 2.0, bearer tokens, and basic auth — and knowing which pattern a given API uses — is the most practical skill any automation builder can develop.

Zapier and Make abstract some of this complexity through their built-in app integrations, but the moment you need to hit a custom endpoint, a niche SaaS tool, or an internal API, you are working directly with authentication headers, token refresh flows, and credential storage. For practical tips on connecting apps to Zapier through its UI, see how to connect apps to Zapier. For the consulting perspective on building these integrations end-to-end, see webhook and API integration consulting. Getting this wrong means silent failures, leaked credentials, and locked-out accounts.

API Keys: Simple but Requires Careful Storage

API keys are static tokens — a string like sk-abc123xyz that you include with every request to prove who you are. They are the simplest auth method and the most common for developer tools, data APIs, and internal systems. The implementation is a single HTTP header: Authorization: Bearer sk-abc123xyz or sometimes x-api-key: sk-abc123xyz depending on the API's convention.

In Zapier, store API keys in the Authentication step of a custom app or pass them via a "Set Header" action in a Webhooks by Zapier step. In Make, store them in a custom HTTP module's Headers section or in a dedicated Connection. Never hardcode API keys directly in a scenario or Zap description — use the credential/connection store so they can be rotated without touching every automation.

OAuth 2.0: The Right Choice for User-Scoped Access

OAuth 2.0 is the standard when your automation needs to act on behalf of a specific user account — reading their Gmail, posting to their Slack workspace, updating their HubSpot contacts. The flow involves: (1) redirecting the user to the provider's authorization page, (2) the user grants permission, (3) the provider returns an authorization code, (4) your app exchanges it for an access token and refresh token.

  • Access tokens are short-lived (typically 1 hour). Your automation must check for expiry and request a new one using the refresh token before making calls.
  • Refresh tokens are long-lived but single-use in some implementations. Store them securely — in Zapier's connection store, Make's connection, or an encrypted environment variable — and never log them.
  • Scopes define what the token can do. Request only the scopes your automation actually needs. "read:contacts" is safer than "admin:all" even if the API offers it.
  • Token rotation: Some APIs (Salesforce, QuickBooks) rotate refresh tokens on every use. If your automation does not capture and store the new refresh token, the next run will fail with a 401.

Bearer Tokens vs. Basic Auth

Bearer tokens are a token format used within the OAuth 2.0 standard — the word "Bearer" in the Authorization header indicates the holder of the token is authorized, no signature required. Basic auth is older: it base64-encodes "username:password" and passes it in the Authorization header. You still see basic auth in legacy SaaS APIs, webhook verification headers, and some internal tools. In Make's HTTP module, there is a dedicated "Basic Auth" setting. In Zapier's Webhooks step, add a header: Authorization: Basic base64(user:pass).

The most common automation auth bug is a token that worked during setup and expired a week later. Build token refresh into the workflow from day one, not as an afterthought when users start reporting failures.

Webhook Signature Verification

When an external service sends data to your automation via webhook, you need to verify the request actually came from that service and was not spoofed. Most platforms (Stripe, GitHub, Shopify) sign their webhook payloads with an HMAC-SHA256 signature using your webhook secret. Your receiving endpoint should compute the expected signature from the raw request body and your secret, then compare it to the signature in the request header before processing the payload.

In Make, use a custom webhook with a filter that checks the X-Signature-256 header against a computed value using the Crypto module. For a broader explanation of how webhooks work and why signature verification matters, see the guide on what is a webhook. In Zapier, you typically need a Code step to perform HMAC verification before passing data to downstream steps.

Storing Credentials Safely in Your Automation Stack

  • Use Zapier's built-in connection manager or Make's connection store — never paste credentials into text fields in a Zap or scenario.
  • For custom Python or JavaScript scripts that call APIs directly, use environment variables set in the platform's secure variable store, not hardcoded strings.
  • Rotate API keys every 90 days and immediately when a team member with access leaves.
  • Use separate API keys for dev/staging and production environments so a test run cannot accidentally modify production data.
  • Audit active connections quarterly — revoke any that belong to apps or users no longer in use.
API IntegrationAuthenticationSecurity

Disclaimer: This article may include links to apps, products, or services. Some links may be affiliate links, which means Automation Ace may earn a commission at no extra cost to you.

Build Better Systems

Ready to automate with confidence?

Share your tools, process, and goals. Automation Ace can design the workflow, integration, AI assist, or code bridge that fits your business.

Start a Project →