What Is an API Key?

Scrapeless Web Unlocker authenticates documented API requests with a Scrapeless API key sent in the x-api-token header.

An API key is a value issued by a service so software can identify itself when making requests. It commonly belongs to an account, project, or application rather than to a human user session. The server checks the presented value and applies its own access and usage rules. The key format, header name, scope controls, and expiry behavior are provider-specific. A client should learn those rules from the current API documentation instead of assuming every key works like a bearer token.

For a web data application, the distinction is practical. A request may reach the correct endpoint yet fail because no key was supplied, the key was sent in the wrong field, or the account lacks access to that product. Conversely, a key that authenticates successfully does not prove the requested URL or payload is valid. This guide treats the key as one part of a controlled request and follows its lifecycle from creation to revocation.

What a Key Identifies and What It Does Not

A provider can issue a key to identify the caller, meter usage, enforce quotas, and associate requests with an account or project. Some systems also allow a key to be restricted by environment, operation, or network origin. None of those restrictions should be presumed unless the provider actually offers them. The key is a credential; the provider’s authorization policy determines what that credential may do at the moment of a request.

A key is not the same as a user password. It often grants machine access without an interactive login, and multiple services may depend on it. It is also not automatically an OAuth access token. The OAuth bearer-token specification describes one presentation scheme; many API key systems use a custom header. Treating every secret as a Bearer value can break authentication or place it where the provider never intended.

The Scrapeless API key guidance says Web Unlocker REST requests send the raw key in x-api-token without a Bearer prefix. The same guidance explains that other Scrapeless interfaces can use different connection methods. Read the selected product guide before moving a credential between a REST client, browser connection, proxy configuration, or SDK.

Where an API Key Belongs in an HTTP Request

The service contract decides whether a credential goes in a header, another transport field, or a specific connection parameter. HTTP headers are common for server-to-server APIs because they keep credentials separate from a resource URL. The HTTP field model explains how request metadata travels with a message. Headers are still visible to the client, proxies under its control, and server logs if those systems record them; a header is not a substitute for TLS or log redaction.

Avoid putting a long-lived key in a URL unless the provider explicitly requires it. URLs can appear in browser history, analytics, referrer flows, reverse-proxy logs, and pasted screenshots. Even a correct header can leak if verbose HTTP tracing prints complete requests. Redact x-api-token and any connection URL that embeds a token before sharing a diagnostic. Store a request ID or safe prefix for support rather than the full credential.

An application should reject an accidental empty key before sending a request. In a server process, read a secret from the deployment environment or secret manager and fail startup if it is absent. A local development shell can load a value for one session, but that does not make the key safe in shell history or a committed configuration file. Keep examples as placeholders and test the real value only in a private environment.

Secure Storage Across Development and Deployment

During development, use an environment variable or a local secret file excluded from version control. A .env file is only storage; the process will not read it unless a loader or application code does so. Shared example files should contain empty values or obvious placeholders. The OWASP hard-coded credential guidance explains why secrets embedded in source code are difficult to contain after distribution.

In production, put the key in the platform’s secret store and grant read access only to the service that needs it. Inject it at runtime rather than baking it into an image or frontend bundle. Audit who can change the secret and which deployments consume it. A browser-side JavaScript application cannot keep a long-lived key secret from the person running that browser; use a trusted backend when the key grants account-level access.

Protect adjacent surfaces too. CI output, error tracking, request tracing, notebook cells, support tickets, and screen recordings can all carry a credential even when the repository does not. Configure automatic redaction for known header names and key patterns, but inspect a representative log to confirm the filter works. Restrict the retention of logs that previously captured secrets and remove exposed copies after revocation.

How to Use a Key Without Misreading Errors

A request has several validation stages. The server checks transport and syntax, identifies the credential, evaluates access, checks product-specific input, and eventually returns a result or error. An authentication failure suggests the key was missing, malformed, expired, or sent by the wrong method. An authorization or balance failure may occur even when the key is recognized. An invalid payload is a separate problem. Change only the layer implicated by the documented error.

Scrapeless documents a Get User Info request as one way to verify key authentication without starting a scraping job. Successful authentication there proves the key worked for that operation; it does not establish access to every product. A small, documented Web Unlocker request can then test the product-specific path. Check the response body as well as the HTTP status and never publish account information returned by a verification call.

The Web Unlocker product page describes URL-based public web retrieval. If a fetched response lacks expected content, avoid treating the key as the likely cause just because the same call used a key. Confirm the target URL, redirects, rendering needs, output type, and source-page identity. Credential validation and content validation answer different questions.

Rotation, Exposure, and Revocation

A planned rotation is a staged deployment change. Inventory the services that use the old key, provision a replacement using the provider’s available controls, update each secret store, restart processes that read secrets only at startup, and verify representative operations. Once the new key is proven, invalidate the old key. Record the cutover owner and time so later failures can be traced to the change rather than guessed at.

An exposed key requires containment first. Invalidate it through the provider’s available controls or support channel, even if this interrupts a job, then issue a replacement and review recent use. Deleting a repository commit or redacting a screenshot does not invalidate a copied key. Preserve enough incident evidence to understand where the exposure occurred, but avoid copying the secret into new tickets while investigating it.

Scope and expiration reduce blast radius when the provider offers them, but they do not remove the need for safe storage. A narrowly scoped key can still reveal data or incur charges within its scope. Separate development and production credentials where the account model supports it. If one key serves several unrelated jobs, rotation becomes harder because every consumer must move together; plan that dependency before an emergency.

Choosing Between API Keys and Delegated Access

API keys work well for a backend service using its own account, especially when the provider offers clear restrictions and revocation. They are a poor way to grant an unrelated third-party application broad access to a user’s account. A delegated authorization protocol can grant bounded access on behalf of a user and provide separate token lifecycles. The right choice depends on the trust relationship, not on which credential looks shorter in an example.

For a client integration, write down who owns the account, where the secret is stored, what it can do, how its use is monitored, and how it will be revoked. If a mobile or browser application must call the provider, consider a backend proxy that authenticates the end user and then makes the provider request from a trusted environment. That backend needs its own authorization checks so it cannot become an open relay.

The related Python API call guide shows the surrounding HTTP mechanics. Keep its transport ideas separate from provider-specific authentication details, which may change. For Scrapeless, current key handling documentation remains the authority for the exact header and verification surface.

Conclusion

An API key identifies a caller under a provider’s access policy. Its safe use depends on the exact request method, controlled storage, redacted diagnostics, and a tested replacement process. Verify the key with a documented operation, then separately verify product access and response content.