Same Wrong Request Type, Four Different Answers: 404 Silence, a Named 405, and Two Venues That Simply Do Not Care

By FeeAtlas — an independent, neutral researcher of exchange fee and specification data. No affiliations with any venue named here.

Disclosure: this article was drafted with AI assistance from measurements taken directly against the exchanges' own public endpoints. Every number and response body quoted below was captured live and can be reproduced by you in under a minute.

Ad/affiliate disclosure (#ad): this site participates in affiliate programs. There are no affiliate or sponsored links in this article — every link is a link to an official exchange document, placed for verification purposes only.

Every trading API tutorial eventually hits the same wall: you sent a POST where the endpoint wanted a GET. On the open web, HTTP gives a clean, standardized answer — status 405, "Method Not Allowed." Case closed.

Crypto exchanges, it turns out, hold four completely different opinions about what should happen. Some do not have the concept at all.

The experiment: one wrong button, pressed five times

Five exchanges expose a clock endpoint that requires no account and no API key: a GET that returns the server's current time. For this test, each endpoint received the same request it did not ask for — an empty POST — twice, on two independent rounds, about one minute apart. Nothing else changed: same machine, same browser-like request header, no body, no credentials.

Measured live on 2026-10-06 at 02:08–02:09 UTC (first detection round: earlier the same day at 00:44–00:55 UTC, identical outcomes).

Answer 1 — Binance: 404, and a completely empty body

POST https://api.binance.com/api/v3/time → HTTP 404, zero bytes returned. Both rounds, exactly the same.

The subtlety is worse than the 404 itself. GET a path that genuinely does not exist on Binance and you also get a 404 with an empty body. The response cannot tell you whether your path is wrong or your method is wrong — "typo in URL" and "wrong verb" collapse into one indistinguishable silence.

Answer 2 — Bybit: 200, and it hands you the time anyway

POST https://api.bybit.com/v5/market/time → HTTP 200 with the same JSON you would get from a GET: retCode: 0, timeSecond, timeNano. The public market endpoints simply do not check the verb. Both rounds identical.

This is friendly the way an unlocked door is friendly. Your script has a bug, and the API rewarded it with success. The bug now lives silently in your codebase until it meets an endpoint that does check.

Answer 3 — OKX: 405 with a name you can grep for

POST https://www.okx.com/api/v5/public/time → HTTP 405 with body:

{"code":"50115","data":[],"msg":"Invalid request type"}

Byte-identical across both rounds. OKX is the only venue of the four that (a) uses the semantically correct 405 status and (b) wraps it in its usual machine-readable envelope with a named error code. The code is documented: re-checking OKX's own docs-v5 error table today (5,247,990 bytes, fetched and searched live) confirms 50115 is listed. If you build per-venue error-handling maps, this is the only venue that hands you a key to put in the map.

Answer 4 — Kraken: 200, and it isn't even pretending

POST https://api.kraken.com/0/public/Time → HTTP 200, same JSON as GET: unixtime and rfc1123. Both rounds.

Kraken's tolerance is at least consistent with its own published self-description: its documentation states that HTTP status codes are generally not used by its API to convey information (errors arrive inside the JSON error array instead). A verb check would be out of character.

The fifth answer that isn't about methods at all

POST https://api.exchange.coinbase.com/time → HTTP 401 {"message":"Unauthorized."} — while GET on the very same path returns 200 with the time.

Read that carefully: the response talks about credentials, not method. Whatever Coinbase does internally, its rejection never mentions the verb, so it tells you nothing about how that venue handles method errors. I record it as a fifth shape — a rejection that answers a question you did not ask — rather than counting it in the four-way comparison. Re-probed a third time: same 401.

Results table (measured 2026-10-06, two rounds each)

Venue	GET /time	POST /time	Dialect
Binance	200, {"serverTime":...}	404, 0 bytes	Ambiguous silence
Bybit	200, full time JSON	200, same JSON	No verb check at all
OKX	200, code:"0"	405, code 50115	Proper 405 + named code
Kraken	200, time JSON	200, same JSON	Status codes carry no meaning (self-documented)
Coinbase	200, iso+epoch	401, "Unauthorized."	Credential-flavored rejection, method unmentioned

Why this matters beyond a chuckle

If you maintain one client that talks to several venues — a fee tracker, a monitoring bot, a backtest data pipe — "wrong HTTP method" is the layer where no shared handling exists. One venue gives a 404 indistinguishable from a bad URL. Two give a success you did not earn. One gives a documented code. One gives an error about something else entirely.

Three practical habits fall out of the table:

1. Parse bodies, not just status codes. A 200 here can mean "you used the wrong verb and nobody noticed." Trusting status codes across venues is exactly the mistake Kraken's own docs warn about.
2. Log raw responses during development. Bybit's and Kraken's tolerance turns method typos into silent drift that surfaces only when a different endpoint on the same venue does enforce the verb.
3. Expect the empty-404 class. Where a venue cannot distinguish "no such path" from "wrong verb" (Binance today), keep a local list of known-good method/path pairs instead of trusting error feedback.

None of this makes one venue's API "better." It is one more reminder, in the same family as tick sizes, price collars and rate-limit stopwatches we've measured before: each exchange writes its own rulebook, including for the parts the HTTP RFC was supposed to have settled decades ago.

Reproduce it yourself

Open a terminal and run, for each venue, one GET and one POST with a browser-like user agent, and compare the status lines. Five URLs:

• https://api.binance.com/api/v3/time
• https://api.bybit.com/v5/market/time
• https://www.okx.com/api/v5/public/time
• https://api.kraken.com/0/public/Time
• https://api.exchange.coinbase.com/time

Verify official sources

Numbers in this article are live observations, not quotes from press releases. Before relying on any endpoint behavior, check the venues' own current documentation:

• Binance spot API docs (error definitions including the -1xxx parameter family): github.com/binance/binance-spot-api-docs
• Bybit V5 docs (market/time endpoint, rate limits): bybit-exchange.github.io/docs/v5/
• OKX V5 API docs (error code table including 50115): okx.com/docs-v5/en/
• Kraken API docs (response format and error convention): docs.kraken.com
• Coinbase Exchange API docs: docs.cdp.coinbase.com

Exchange behavior changes without notice. What you can verify in one terminal command is worth more than any summary, including this one.

---

This article is provided for information and technical reference only. It is **not financial advice, not a recommendation of any exchange, and contains no trading guidance. Exchange API specifications and behaviors change at any time; always confirm against the official documentation of each venue.