API Key

Overview

An API key is a password for software

When one program calls another over an API, the receiving service needs to know whether the caller has permission. An API key is a credential included with a request, typically in a header, that identifies or authorizes an integration. It is closer to a specialized password than to a cryptocurrency private key. A blockchain private key authorizes digital-asset transactions; an API key authorizes actions offered by a particular service. Their exposure risks differ, but both can create serious damage if mismanaged.

How the underlying system works

A well-run integration assigns credentials to specific environments and responsibilities. Payment creation, account inquiries and outbound payouts need not have the same privileges. Store keys in server-side secret management, restrict who can read them, rotate them when exposed and monitor usage patterns for anomalies. Logging full request headers can unintentionally disclose the very key meant to protect access.

API keys identify or authorize callers but do not always authenticate individual end users. They also do not prove that a webhook came from the provider unless the provider's webhook specification uses the relevant secret in a signature scheme. OxaPay documents distinct merchant, payout and general keys for different API families; choose the key intended for the particular endpoint.

How scope changes the damage of a leak

Imagine a storefront integration that only needs to create payment invoices. If it stores an all-powerful credential in public browser JavaScript, anyone loading the page might copy that credential and call sensitive endpoints. A safer design stores server-side secrets and grants each component only the capabilities it needs. Separate invoice-creation from payout authorization when the service supports different keys or roles. Restrict key visibility, rotate compromised credentials, use HTTPS and log changes. Where a provider offers IP allowlisting or granular permission scopes, assess whether those controls fit the deployment.

What it does not prove

A valid API key proves that a request had the credential; it does not prove that the merchant made a wise business decision. It also does not verify a payment webhook automatically unless the provider explicitly uses that key in its signing protocol. Avoid placing secrets in URLs, analytics events, customer support screenshots or source-control commits. Have a recovery procedure for a leaked key: revoke or rotate it, inspect recent activity, replace it in deployment secrets and verify that existing integrations still work.

Further reading and related concepts

Reference documents: OxaPay — Payment Information, OxaPay — Generate Payout.

Related glossary topics: Merchant API Key, Webhook Signature, Crypto Payout.