The signed request includes the exact route

An API key can be valid and the request can still fail authentication. The signature is not a sticker attached to the request; it is a fingerprint of the request that will actually cross the wire.

Polymarket's API documentation separates wallet control from private-request authentication, then binds each private request to fresh and exact request data.

Keep the two layers separate

L1 uses a wallet signature to establish control and create or derive credentials. L2 signs private CLOB requests with the API secret using HMAC-SHA256.

A process that mixes those layers in one generic ‘auth passed’ flag loses the reason a request was accepted or rejected.

Sign what you send

For L2, the message includes a new Unix timestamp, the uppercase HTTP method, the route path, and the exact serialized body when a body exists. A different path or a different serialization produces a different message.

Build the body once, serialize it once, sign that exact string, and send the same bytes. Pretty-printing or reordering fields after signing is a request change, not a harmless formatting step.

Treat time as an input

The timestamp belongs to the signature and to the authentication headers. Generate it for the request, keep it beside the signature metadata, and do not reuse a stale value across retries.

A retry can use the same business action while still needing a new authentication envelope. Log the route and timestamp, but never log the secret or passphrase.

Make failures diagnosable

When authentication fails, compare the signed method, path, body hash, timestamp, and headers without exposing credentials. This narrows the problem to routing, serialization, clock drift, or credential state.

The useful question is not whether the API key exists. It is whether the signed message describes the exact request that the server received.

Further reading: API overview · Wallets and authentication · Place orders.

Explore the markets: Open Polymarket (referral link).