API Security: Authentication & Encryption — Full Guide 2026

Your prospecting tools, your CRM, your data enrichment platform — they all communicate through APIs. And every API call is a potential entry point into your B2B data. According to Salt Security, API attacks increased by 167% in 2024 alone. For a sales or growth team, a compromised API key can mean thousands of leaked prospect contacts, a hijacked LinkedIn business account, or worse — a GDPR violation that carries fines of up to 4% of global annual revenue.

This guide breaks down how API security actually works, which authentication methods to use depending on your setup, and how to encrypt your data exchanges so you can work without risk.

Enrich your leads securely

Derrick connects to your Zapier, Make, and n8n workflows using secure protocols. Try it free — no credit card required.

Try for free →

Why API Security Is Now a B2B Team Problem

API security used to be something only developers worried about. Not anymore.

Today, an SDR configures Zapier webhooks, a Growth Marketer connects Derrick to HubSpot via Make, and a Sales Ops manager exports leads into Salesforce through a RESTful API. Every one of these workflows runs on API calls — and every one of them potentially exposes sensitive data.

The consequences of a security gap are very concrete for business teams:

• Prospect data theft: an API key left in a public GitHub repo or a shared Notion doc is all it takes for a third party to access your lead database.
• GDPR violations: personal data (emails, phone numbers) transiting through an unsecured API puts you in breach of regulation. Under GDPR, fines can reach €20 million or 4% of global annual turnover — whichever is higher. The ICO in the UK enforces similar rules post-Brexit.
• Service disruption: an attacker can drain your API credits (and budget) within minutes using a brute-force attack or an abuse of your rate limits.

Getting a handle on API security basics means protecting both your sales pipeline and your legal obligations. Let’s start with the fundamentals.

What Is an API and Why Do Attackers Target Them

An API (Application Programming Interface) is a standardized communication channel between two applications. In practice: when Zapier asks Derrick to find a prospect’s email, it goes through an API. When you export leads to HubSpot, your tool sends a request to the HubSpot API.

What makes APIs attractive targets is their nature: they’re accessible from anywhere, often publicly documented, and process high-value data (contacts, access tokens, financial records).

The most common attack vectors in B2B contexts:

• Exposed API keys in version-controlled code (GitHub), shared config files, or misconfigured no-code tools.
• Credential stuffing: testing thousands of username/password combinations using leaked credentials from other breaches.
• Man-in-the-Middle (MITM) attacks: intercepting unencrypted API requests on an insecure network.
• Permission abuse: accessing data a token was never supposed to reach, due to overly broad scopes.

With that context in place, let’s get into the methods that actually protect your API integrations.

The 4 API Authentication Methods You Need to Know

Authentication answers one question: “Are you actually who you say you are?” There are four main approaches, each with different security levels and use cases.

1. API Keys: Simple and Fast, But Handle With Care

API Keys are the most common authentication method in no-code tools and B2B integrations. It’s a unique string (e.g., sk_live_abc123xyz) you include in every request to identify yourself.

Strengths: Easy to generate, revoke, and use in Zapier or Make without complex configuration.

Limitations: If a key is compromised, anyone can use it. It carries no built-in permission data, so access control has to be managed server-side.

Best practice: Create one key per integration (one for Zapier, one for Make, one for n8n). If a key leaks, you revoke only that one without disrupting your other workflows.

2. OAuth 2.0: The Standard for Delegated Access

OAuth 2.0 is the protocol you already use every time you click “Sign in with Google” or “Authorize LinkedIn access.” It lets an application access a user’s data without that user sharing their password.

How it works in practice: the application requests a temporary access token (typically valid for 1 hour), which the user approves through an interface. That token is then used in API requests instead of credentials.

Why this matters in B2B: if you connect your CRM to a third-party tool via OAuth and that tool gets breached, the attacker only gets a short-lived token — not your password. You can revoke access in a few clicks from your account settings.

3. JWT (JSON Web Token): Stateless Authentication

A JWT is an encrypted token that embeds information directly — user identity, permissions, expiration date — all encoded in the token itself. The server doesn’t need to query a database to validate each request; it simply decrypts the token.

In B2B contexts, JWTs are common in microservice architectures and SaaS platforms handling large numbers of concurrent users. The tokenization model they enable reduces the attack surface compared to traditional session-based authentication.

Key point: An expired JWT is automatically invalid. Always configure short expiration windows (15 minutes to 1 hour) for sensitive tokens.

4. Basic Authentication: Development Only

Basic Auth sends a Base64-encoded username and password with every request. It’s simple to implement but dangerous in production — Base64 is encoding, not encryption, and credentials are trivially decodable if the connection isn’t encrypted.

Hard rule: Never use Basic Auth without HTTPS. In practice, keep it to local development environments or fully controlled internal networks.

How API Encryption Works

Authentication proves who you are. Encryption protects what’s traveling. The two are inseparable in a solid security strategy.

TLS/HTTPS: The Foundation of Secure Communication

TLS (Transport Layer Security) is the protocol that encrypts data between your browser (or application) and the server. When a URL starts with https://, TLS is doing the work.

For APIs, there’s no exception: any API exposed on the internet must run exclusively over HTTPS. An HTTP API transmits data in plain text — like sending mail without an envelope.

In practice, always verify that third-party APIs you integrate (data enrichment, CRM, automation) use TLS 1.2 or 1.3. Older versions (SSL, TLS 1.0) have known vulnerabilities and should be considered insecure.

Encryption at Rest vs. Encryption in Transit

Data encryption covers two distinct states:

For B2B teams, in-transit encryption is most critical: that’s where your prospect lists, tokens, and personal data travel with every API call. Encryption at rest is more the SaaS provider’s responsibility — ask them explicitly whether it’s applied.

HMAC Request Signing

For critical integrations — especially webhooks — HMAC signing adds an additional layer: each request is signed with a shared secret key. The receiving server verifies the signature before processing the request, guaranteeing the request wasn’t tampered with in transit.

In practice, platforms like Stripe and HubSpot use this on their webhooks. If you’re building Make/Zapier workflows that receive webhooks, confirm that signature verification is active on the receiving end.

Best Practices to Secure Your B2B API Integrations

Now that the concepts are clear, here are the rules to apply concretely in your prospecting and enrichment workflows.

1. Apply the Principle of Least Privilege

Every API key or token should have only the permissions strictly necessary for its task. A token that reads contacts in your CRM has no business accessing billing settings.

In practice: when creating an API key in any tool, look for “scopes” or “permissions” and check only what you actually need. Most B2B tools (HubSpot, Salesforce, Zapier) offer this level of granularity.

2. Rotate Your Keys Regularly

An API key that’s been active for two years has had plenty of opportunities to be exposed — team turnover, repo migrations, uncleaned logs. Key rotation — generating a new key and revoking the old one — is a security baseline.

Recommended frequency: every 90 days for critical keys (data enrichment, CRM access). Immediately whenever a team member with access to configurations leaves.

3. Implement Rate Limiting

Rate limiting caps how many requests a given API key can make within a set time period. It protects against:

• Brute-force attacks (attempting thousands of combinations)
• Accidental credit drain (if your tool charges per API call)
• Infinite loops from a misconfigured automation workflow

On the provider side, verify that the APIs you use enforce rate limits. On the consumer side, set up alerts if your quotas are exceeded abnormally.

4. Log and Monitor Every API Call

You can’t protect what you can’t see. A good API activity log lets you spot suspicious patterns: calls from an unknown IP, unusual volume at 3 a.m., access to unfamiliar endpoints.

For non-technical teams, automation platforms like Make and Zapier provide execution histories you can review regularly. It’s less powerful than a full SIEM solution, but enough to catch obvious anomalies.

5. Never Hardcode API Keys in Files or Shared Documents

This is the most frequent mistake — and the most costly. An API key hardcoded in a Google Sheet, a public GitHub repo, or a Notion page shared across the company is enough to expose your entire stack.

Better alternatives:

• Use the credential managers built into your automation platforms (Zapier and Make both have dedicated secrets sections)
• Store keys in environment variables if you’re working with code
• Use a dedicated secrets manager (1Password for Teams, HashiCorp Vault) for larger teams

The Most Common API Security Mistakes (And How to Fix Them)

Problem 1: API Key Exposed in a Shared File

Impact: Anyone with access to that file can use your key to consume your credits, access your data, or make requests on your behalf.

Solution: Revoke the exposed key immediately from the tool’s interface — don’t wait. Generate a new one and reconfigure your integrations. Then audit all shared files (Notion, Confluence, Google Drive) for any other occurrences.

Problem 2: OAuth Token Never Revoked After an Offboarding

Impact: A former team member retains valid access to your CRM, enrichment tool, or LinkedIn business account.

Solution: Maintain a list of active OAuth connections in each tool (usually under “Connected Apps” or “Authorized Applications” in settings). Make it part of your offboarding checklist to review and revoke relevant access.

Problem 3: Using HTTP Instead of HTTPS

Impact: All data in that API call — emails, tokens, prospect data — travels in plain text and is readable by anyone intercepting the traffic.

Solution: Verify that every API base URL you integrate starts with https://. Refuse to use any tool that offers endpoints over http:// for sensitive data.

Problem 4: Overly Broad Scopes Granted to a Third-Party Integration

Impact: If the third-party tool is breached, the attacker gets far more access than was necessary — email reading, billing information, admin settings.

Solution: Review the permissions granted to each integration. In HubSpot, Salesforce, or your CRM, the “Connected Integrations” section shows exactly what each app can do. Reduce to the strict minimum.

Problem 5: No Key Rotation After a Security Incident

Impact: Even if the incident is contained, an unrevoked key remains a potential exploitation vector.

Solution: Adopt a policy of systematic revocation whenever a key may have been exposed — even without proof of malicious use. Reconfiguring an integration always costs less than responding to a data breach.

APIs, GDPR, and Personal Data: What B2B Teams Must Know

In B2B, data enrichment APIs process personal information: names, professional email addresses, phone numbers. That puts them squarely within GDPR scope — and equivalent regulations like the UK GDPR enforced by the ICO.

What this means practically:

• Legal basis: You need a documented legal basis for processing data through APIs. In B2B, legitimate interest typically applies, but it must be documented in your Records of Processing Activities (RoPA).
• Cross-border transfers: if a US-based API provider transfers personal data to American servers, adequate transfer mechanisms must be in place (Standard Contractual Clauses, or the EU-US Data Privacy Framework).
• Retention limits: data retrieved via API shouldn’t be kept indefinitely. Define a data purge policy for your Google Sheets and CRM records.
• Technical security: GDPR Article 32 requires appropriate technical measures, including encryption. An API without HTTPS isn’t compliant with the regulation’s security requirements.

Questions to ask your B2B API providers:

1. Where is data processed and stored — EU, US, or elsewhere?
2. Is TLS encryption applied on all endpoints?
3. Is a Data Processing Agreement (DPA) available?
4. How is data encrypted at rest?

Any serious provider answers these four questions clearly. For a deeper dive on GDPR compliance in outbound prospecting, see our guide on cold emailing and GDPR.

How to Evaluate the Security of a B2B Data Enrichment API

When you evaluate a B2B enrichment tool — whether for email finding, phone enrichment, or company data — security should be a selection criterion alongside data accuracy.

The security checklist:

Derrick integrates natively with Google Sheets and supports secure connections through Zapier, Make, and n8n. You can configure separate keys per workflow and revoke individual access from your dashboard — making it straightforward to manage permissions across your team.

To learn more about building secure enrichment workflows for your B2B outreach, check out our guide on database enrichment.

Key Takeaways

• Authentication ≠ encryption: both are necessary and complementary — one proves your identity, the other protects what’s in transit.
• OAuth 2.0 is the recommended standard for delegated access; API Keys work well for machine-to-machine integrations, provided you manage their lifecycle carefully.
• HTTPS/TLS is non-negotiable: any API exposed on the internet without in-transit encryption is a security flaw.
• One key per integration: create distinct keys per workflow so you can revoke precisely in case of an incident.
• GDPR applies to personal data processed through APIs: legal basis, transfers, retention, and technical security are all in scope.
• Rotate your keys every 90 days and immediately whenever team composition changes.

Conclusion: Where to Start Today

API security isn’t just a developer problem. As a business professional configuring enrichment, automation, or lead export workflows, you’re on the front line.

Start with a simple audit: list every active API key and OAuth token across your tools — Zapier, Make, your CRM, your enrichment platform. For each one, ask three questions: who has access, since when, and with what permissions.

The payoff is immediate: lower risk of prospect data leaks, stronger GDPR compliance, and a security posture that builds trust with the very prospects you’re reaching out to.

Secure, scalable enrichment workflows — starting now

Derrick gives you fine-grained access control for your enrichment workflows, natively in Google Sheets. No credit card needed to get started.

Try for free →

FAQ

What’s the difference between API authentication and encryption? Authentication verifies the identity of whoever is making the request (via an API key, OAuth token, or JWT). Encryption protects the data inside that request as it travels (via TLS/HTTPS). Both are required: an authenticated but unencrypted request can still be read in plain text by anyone intercepting the traffic.

Is an API Key enough to secure a B2B integration? For simple use cases (read-only access from a trusted tool), yes — provided you follow best practices: one key per integration, regular rotation, and secure storage in your automation platform’s credentials section (never hardcoded in a file). For more sensitive access involving personal data, OAuth 2.0 offers better isolation and easier revocation.

How do I know if an API I’m using is secure? Check that the base URL starts with https://, that the provider offers a DPA (Data Processing Agreement), and that their documentation mentions TLS. Also verify whether endpoints support rate limiting and whether authentication includes granular scope options.

Do my Zapier or Make workflows fall under GDPR? Yes, if they process personal data — emails, phone numbers, prospect names. Automation platforms like Zapier and Make are considered data processors under GDPR. Make sure a DPA is in place with them, and that data doesn’t flow outside the EU without appropriate safeguards. In the UK, the ICO enforces equivalent requirements under UK GDPR.

What should I do if I discover an API key has been exposed? Revoke it immediately from the tool’s interface — don’t wait to assess the damage first. Generate a new key and reconfigure your integrations. Then review usage logs to check for abnormal activity. If personal data may have been compromised, GDPR requires notifying your supervisory authority (ICO in the UK, relevant DPA in your EU country) within 72 hours.