Signed API Requests

Signed API requests are HTTP requests that carry a cryptographic signature derived from selected request data and a secret or private key. The server rebuilds the same signing input, verifies the signature, and rejects the call when the values do not match. This matters in trading and automation because order placement, withdrawals, account changes, and webhook actions often need stronger proof than an API key sent by itself.

How API Request Signing Works

API request signing turns a normal request into a tamper-evident message. The client first builds a deterministic string from fields such as the HTTP method, path, query parameters, body hash, timestamp, and selected headers. It then signs that string and sends the result in an Authorization header, a custom header, or a query parameter.

1. Collect the exact fields required by the provider.
2. Canonicalize them into one stable byte sequence.
3. Create the signature with an HMAC secret or private key.
4. Send the request with its key identifier, timestamp, and signature.
5. Let the server rebuild and verify the same sequence.

A signature does not encrypt the payload. HTTPS still protects data in transit. Signing adds authentication and integrity, while timestamps or nonces help block replayed requests.

HMAC, RSA, and Ed25519 Schemes

Many exchange APIs use HMAC, while some now support RSA or Ed25519. A Binance Ed25519 signed request, for example, uses an asymmetric API key pair. The algorithm is only one part of the contract; parameter order, encoding, and timestamp rules still have to match the provider exactly.

Canonicalization Is Where Bugs Hide

Most failed signatures come from canonicalization, not broken cryptography. A request can look identical in logs yet produce different bytes because one library encodes spaces as %20 and another uses +, sorts duplicate query keys differently, changes header case, or serializes JSON with different whitespace.

A common failure mode appears when code signs a body object and the HTTP client later reserializes it. The server hashes the bytes it received, not the object the application meant to send. Operators usually verify this by logging the final canonical string, its byte length, the body hash, and the request timestamp on both sides. Secrets and full authorization headers should be redacted.

• Sign the final bytes, not an earlier data structure.
• Freeze query sorting and percent-encoding rules.
• Normalize only the headers named by the protocol.
• Use a constant-time comparison when verifying HMAC values.
• Check clock drift before changing keys or permissions.

Signing AWS API Requests and API Gateway Calls

AWS uses Signature Version 4, usually called SigV4. To create a signed AWS API request, the client builds a canonical request, hashes it, creates a string to sign, derives a signing key from the date, Region, service name, and AWS secret, then adds the signature to the request. For API Gateway routes protected by IAM, the service name is normally execute-api.

The credential scope must match the target Region and service. A request signed for the wrong Region can fail even when the access key and IAM policy are valid. Temporary credentials also require the session token. This is why signing AWS API requests by hand is fragile; AWS SDKs, the AWS CLI, and supported Postman authorization helpers remove many formatting errors.

An AWS API Gateway signed request in Java, PHP, Python, or C follows the same SigV4 steps. In C, use a trusted SHA-256 and HMAC library, build the canonical request as bytes, derive each HMAC stage without converting intermediate values to text, and hex-encode only where the SigV4 format requires it.

Platform Examples and Similar-Sounding Terms

The phrase sign API request covers several protocols that are not interchangeable. Cloudinary signed uploads hash a provider-defined parameter string and keep the API secret on the server. Slack request verification signs a timestamp plus the raw request body, so parsing JSON before verification can destroy the original byte sequence. OAuth 1.0, used by older Twitter API flows, has its own parameter normalization and signature-base-string rules.

Other search phrases refer to different jobs. A Dropbox Sign API signature request sends a document for electronic signature; it is not the same as cryptographically signing the HTTP call. The same distinction applies to RightSignature signer sequencing, Zoho Sign errors, and a certificate signing request, or CSR. Facebook's signed_request is a signed payload format, while Google URL signing protects a URL rather than every API request.

Tools can help, but they can also hide the crucial bytes. Postman can sign an API request when it supports the provider's scheme. For custom schemes, a pre-request script may be needed. Production services should prefer maintained SDK signers or small, tested signing modules instead of copying an old Amazon Product Advertising API PHP signed request example or sample C code without checking the current protocol.

Failure Modes, Security, and Maintenance

A 401 or signature mismatch does not always mean the key is wrong. The cause may be a stale timestamp, missing session token, changed host header, proxy rewrite, wrong body hash, incorrect key permission, or a server that expects the raw body. Retry logic can make matters worse if it reuses an expired timestamp or nonce.

• Compare the canonical request field by field.
• Confirm the server clock and client clock are close.
• Verify the signing key has permission for the exact operation.
• Check whether a proxy, gateway, or SDK changed signed headers.
• Rotate keys without allowing two services to overwrite each other's credentials.

Keep signing secrets in a secrets manager, hardware security module, or managed key service where the platform supports it. Restrict keys by action, account, IP, or environment. Signed requests add code, clock handling, and key rotation work, so they are not a replacement for TLS, authorization checks, rate limits, idempotency controls, or audit logs. They are one strong layer, not the whole security model.