SERP API Key Security: Keep Credentials Out of Client Code

An API key is the credential your code sends when it calls the SERPpost V1 API. After you create an account, open the Dashboard and choose API Keys to access or copy the current key. Send it only from server-side code or a controlled worker, never from JavaScript shipped to a visitor’s browser.

This guide is for developers wiring SERPpost into an application. It covers where to access the key, the documented Authorization header, and the habits that keep a credential out of a bundle, a repository, or an application log. It does not document key rotation, key scopes, IP restrictions, plan limits, or pricing because those controls are not described here.

Access the API key in the Dashboard

The account flow is short:

1. Create a SERPpost account.
2. Open the Dashboard and select API Keys.
3. Copy the value only into the server or worker that will send the request.

The API Keys page is where the product exposes the current credential. Treat the copied value as you would a password. A browser extension, screen recording, support ticket, screenshot, or pasted terminal output can all turn a private value into a public one.

Send the key in the documented Authorization header

SERPpost V1 uses a Bearer token in the Authorization header. The smallest useful search request looks like this:

curl -X POST https://serppost.com/api/v1/search \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "s": "site reliability engineering",
    "t": "google",
    "p": 1,
    "d": 20000,
    "country": "us",
    "language": "en",
    "maxCache": 0
  }'

This is a request shape, not a promise about the response for a particular query. The SERPpost V1 Docs list the current result types and explain how to inspect the response before your application uses it. Use POST /api/v1/url when your workflow already has a public URL and needs Reader output; do not substitute the old /api/search path.

Keep the credential out of client code

Client code is any code delivered to the browser. A variable hidden behind a build step is still available to someone who can load the page if the browser needs it. That makes a frontend bundle the wrong place for a long-lived API credential.

Put the key in the secret configuration of the server, worker, or job that sends the request. The browser can call your own authenticated backend endpoint, while the backend adds the SERPpost Authorization header. This keeps the credential on the side of the system you control.

For local development, an ignored environment file can keep a value out of a repository, but it is not a complete secrets-management system. For a deployed application, prefer the managed secret facility offered by the platform that runs the job. OWASP notes that environment variables can be available to other processes and can appear in logs or system dumps, so treat them as a runtime detail to review rather than a guarantee of secrecy. OWASP’s Secrets Management Cheat Sheet provides the broader context.

A minimal server-side example

This JavaScript example assumes the runtime provides fetch. It reads the credential from the server environment and sends one documented V1 search request.

const apiKey = process.env.SERPPOST_API_KEY;

if (!apiKey) {
  throw new Error('SERPPOST_API_KEY is not configured');
}

const response = await fetch('https://serppost.com/api/v1/search', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${apiKey}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    s: 'site reliability engineering',
    t: 'google',
    p: 1,
    d: 20000,
    country: 'us',
    language: 'en',
    maxCache: 0,
  }),
});

const body = await response.json();

if (body.code !== 0) {
  throw new Error(`SERPpost request failed with code ${body.code}`);
}

// Read only the response fields your application needs.

The Docs describe code: 0 as a successful request. Keep the error you log separate from the headers you sent. A useful log line can contain an HTTP status, the API response code, and a request identifier when one is returned. It should not contain the full Authorization value. OWASP’s Logging Cheat Sheet lists access tokens, passwords, encryption keys, and other primary secrets among data that should be removed, masked, sanitized, hashed, or encrypted before logging.

Check the places where credentials leak

Most leaks are mundane. A developer copies a working command into an issue, commits an environment file, or prints an entire request object while debugging. A short review catches more than another policy document.

Before you merge or deploy, check these places:

• Environment files are ignored by Git and are not included in build artifacts.
• Browser code does not contain SERPPOST_API_KEY, an Authorization value, or a copy of the request header.
• Request logging redacts the Authorization header and any object field that stores the key.
• CI logs, screenshots, sample notebooks, and support tickets use YOUR_API_KEY rather than a real value.
• A backend route or worker, not the browser, sends the request to SERPpost.

If you suspect that a real key appeared in public content, remove the exposed value from the public location first. Then follow the account handling path available to you rather than assuming that changing a visible string removes copies from repository history, logs, caches, or screenshots. GitHub explains that secret scanning can inspect Git history and other repository surfaces for hardcoded credentials, including API keys. Treat scanning as a backstop, not a reason to put a real key in version control. See GitHub’s secret-scanning documentation.

Verify the integration without exposing the key

The safest first test is small and deliberate:

1. Access the key from Dashboard > API Keys.
2. Use the API Playground or a server-side test to send one representative request.
3. Check the HTTP result and the response code before your application parses data.
4. Inspect the logs to make sure the Authorization value is redacted.

The Playground is useful for confirming the V1 request shape before you put the same credential in a backend job or worker. It does not replace a production test of your own authentication, logging, and deployment configuration.

FAQ

Where do I find my SERPpost API key?

After you have an account, open the Dashboard and choose API Keys. That page is the current account location for accessing or copying the credential.

What header does SERPpost use for authentication?

Use Authorization: Bearer YOUR_API_KEY with the V1 request. The current endpoint and body examples are in the SERPpost V1 Docs.

Can I put the key in frontend environment variables?

Do not put a SERPpost API key in configuration that is delivered to the browser. Put it in the environment or secret store for the server or worker that sends the request instead.

Should I log the API key while debugging?

No. Log the HTTP result, API response code, or a request identifier if your response includes one. Redact the Authorization header and avoid logging request objects that include the credential.

Does this guide explain every API-key account control?

No. It explains where to access the current credential, how to send the documented header, and how to avoid exposing the value in application code. Check the Dashboard and Docs for current account and API details.

Keep the credential server-side, test one request, and make sure your logs do not retain the Authorization value. For endpoint details and result types, continue with the SERPpost V1 Docs.