Bybit API Guide: Authentication, Testnet and First Connection

Bybit documents its V5 API across REST and WebSocket surfaces, testnet, market categories, and order-type values. That documentation gives a developer a place to start an integration review. It does not settle access, eligibility, security, or execution questions.

Start by separating private-access requirements from one harmless public request. A successful public request shows that the endpoint responded and that the application can parse the response. It says nothing about an account, a product, a location, or an intended use.

Check the public server-time endpoint

Make the documented unauthenticated request:

curl https://api.bybit.com/v5/market/time

For a successful response, check that:

retCode is 0.
retMsg is OK.
The result includes timeSecond and timeNano.

This checks public connectivity and response parsing. It does not authenticate a key, confirm permissions, validate an account, or test trading.

Credentials and authentication

An API key is a credential for authenticated requests. Bybit's integration guidance directs users to testnet or mainnet to generate a key where that surface is available. It distinguishes system-generated HMAC keys from auto-generated RSA keys; on the RSA route, the user creates a key pair and provides the public key to Bybit.

Authenticated requests use documented inputs that include an API key, timestamp, signature, and an optional receive-window header. GET and POST signing inputs differ, as do the documented HMAC and RSA signature encodings. Those are request-construction details. They do not prove that a key has the permissions a workflow needs or provide a security guarantee.

Do not put an API secret, private key, seed phrase, password, or withdrawal credential in a script, chat, repository, or shared configuration. Local examples should use placeholders such as YOUR_API_KEY and YOUR_API_SECRET.

Transport and SDK overview

REST fits request-and-response calls. Public WebSocket topics cover the documented public streaming surface. Private REST requests and private WebSocket topics belong to a later, authenticated stage.

Keep the boundary clear: public connectivity and private authentication are separate checks.

The table is an overview of documented surfaces, not an operational path.

Documented area	What it lets you investigate	Important boundary
REST API	Make documented HTTP requests to API endpoints.	A reachable public endpoint does not show that a private workflow will work.
WebSocket	Inspect public, private, trade, and system-status stream surfaces. Public topics do not require authentication; private topics do.	A documented surface is not a promise of data or product access.
Official SDKs	Begin an implementation review in Python, Go, Rust, Ruby, JavaScript, PHP, Java, or .NET.	The documentation does not establish feature parity or support quality across SDKs.
Categories and order labels	Read `spot`, `linear`, `inverse`, and `option` category values, plus `Market` and `Limit` order-type values.	Field values do not establish category availability or an execution outcome.
Testnet	Keep an initial environment investigation separate from mainnet work.	Testnet does not establish account, product, geographic, or production access.

Environments

Bybit documents mainnet, testnet, and some regional API domains. Keep a key and its domain in the same documented environment. Its error reference notes environment/key mismatches across mainnet, testnet, mainnet-demo, and testnet-demo. A regional domain or testnet endpoint remains technical documentation, not an eligibility decision.

Controls and operational boundaries

Use only the access needed for the work under review. Public data can come before a test environment where applicable, and private capability can remain narrow.

Permission-denied and unmatched-IP error signals show that API-key permissions and bound IP addresses can matter. They are not instructions for configuring an account.

Rate limits affect implementation behavior. Bybit documents an HTTP IP default of 600 requests per five-second window, endpoint-specific rolling per-second UID limits, and WebSocket connection limits. Limits can vary by endpoint and tier, so retry, pacing, and error handling need to follow the current documentation rather than one assumed number.

Products, orders, and errors

The documented category labels are spot, linear, inverse, and option; the order-type values here are Market and Limit. They describe parameters, not product access or order behavior.

When a request fails, the documented error meaning can narrow the next check:

Signal	What the documentation says to check
`10002`	The request time exceeded the allowed window.
`10003`	The API key and domain/environment match.
`10004`	The signature-generation algorithm.
`10005`	API-key permissions.
`10006`	Whether the API rate limit was exceeded.
`10009`	Whether service access is restricted for the region.
`10010`	API-key bound IP addresses.

A code is a troubleshooting clue, not a complete diagnosis. It cannot establish eligibility, product availability, or whether a change will resolve the problem.

Account and geographic limits

Bybit documents Standard identity verification as mandatory for its products and services. Its V5 integration guidance states that requests from IP addresses in the US or Mainland China are restricted and return HTTP 403. Another documented signal can report region-restricted service access.

Check current terms, account requirements, product conditions, and the rules that apply where you are located.

What to check next

Use the server-time response to confirm public connectivity. Then review private authentication, permissions, account requirements, and location or product questions separately before spending time on a private integration. This page does not recommend a venue or authorize an implementation.