Community API Wrappers That Automate Quotex, Compared

Every library here wraps the unofficial Quotex API

Start with the part that is already settled: there is no broker-published Python SDK. Quotex holds a GitHub organization account and it carries no public repositories at all — nothing to install, nothing to read, no versioned client that anyone official maintains. Whether a sanctioned Quotex API will ever appear, and what requesting access would involve, is a separate question this page assumes you have already asked.

So every project below is a community wrapper. Someone watched the platform's own web client talk to its servers, worked out the message format, and reimplemented that conversation in Python. That is a normal way to automate a platform that never shipped a broker API — and it carries four consequences worth internalising before you install anything.

• It can break on an ordinary Tuesday. The platform owes these projects no deprecation notice, no changelog and no stable contract. A login flow that worked last month can stop working after one front-end deploy.
• It wants your real credentials. Every wrapper here signs in as you, with an email and password or a session token lifted from a browser session. You are handing an unaudited package the keys to a funded account.
• The platform's terms govern your account, not the library's license. An MIT license grants you rights over the code. It grants you nothing at all with respect to the broker.
• The transport is a socket, not a tidy REST endpoint. These libraries hold a WebSocket streaming connection open and react to pushed messages, which is why every serious one is built on asyncio.

If you want to go a level below the wrapper and read the raw handshake and message format yourself, that is its own subject — the unofficial WebSocket protocol deserves a separate read, and none of these libraries hide it from you.

Not every "quotex" repo on GitHub is a trading library

A reader searching for Quotex code hits the decoys before the real libraries, so clear them first. These are not obscure edge cases — they rank on the obvious query and they look plausible until you open the README.

• mohamadadithya/quotex is a random-quote web app built on Bootstrap, pulling from a third-party quote generator. It shares four letters with the broker and nothing else.
• Davidthecode/QuoteX is a Chrome extension that puts an inspirational quote with author attribution on your new-tab page. JavaScript, no trading surface anywhere.
• Packaged signal products dressed as repositories. Some entries under the Quotex and qxbroker topics are not importable libraries at all — they are bots or signal engines whose description leads with a headline win rate and a promise of round-the-clock autopilot. There is no client class to import, and any repo that advertises an accuracy figure in its one-line description is selling, not documenting.
• Re-uploads of the same tool. More than one account publishes the same historical-candle downloader with a near-identical description. One of them has the commit history; the others are copies. Compare creation dates and commit counts before you build on either.

Three checks take about ten seconds and remove all four categories: is the language tag Python, does the README show an import plus a login call, and does the description describe an interface rather than a result?

Best open-source Quotex Python libraries on GitHub, compared

Four projects are worth your time. The columns below are deliberate: stars tell you what was popular a year ago, whereas the login method tells you whether it will run on your server, the license tells you whether you can ship what you build, and the upkeep signal tells you whether it still matches the platform's current behaviour.

Two patterns fall out of that table immediately. Every one of these libraries is asynchronous, so if your codebase is synchronous you are wrapping calls in an event loop regardless of which you pick. And the easiest one to install is the least actively maintained, which is exactly the trade you have to make consciously rather than by accident.

pyquotex — the community default

pyquotex by Cleiton Leonel Creton is the project the rest of the ecosystem builds on and forks from. It is the only one here with a real documentation site rather than a README — authentication, trading operations, market data, indicators and socket handling each get their own page, in more than one language. Functionally it covers what a bot needs: connect, pull candles, place a buy or sell, switch between practice and live balances, and close cleanly.

It is also the only one in the table still receiving commits this year, which matters more than any other attribute for software that tracks an interface it does not control.

The deciding trade-off is its license, not its code. The repository ships a GPL-3.0 license file while the package metadata declares MIT, and GitHub's own license detection consequently reports nothing conclusive. For a personal script that is noise. If you intend to distribute anything built on it — a hosted service, a product, a client deliverable — that ambiguity is a question for whoever signs off on your dependencies, and the honest move is to open an issue and ask the author rather than pick the interpretation you prefer. Practical notes: it installs from Git rather than PyPI, and it targets a recent Python.

On forks. GitHub gives a fork no visual distinction in search results, so people either pick one blind or dismiss every fork as stale noise. Both are wrong here. iahmedani/pyquotex is an actively developed fork that states its lineage openly and adds things upstream does not have: multiple login profiles, proxy and DNS configuration, TLS impersonation for hosts that fingerprint clients, auto-reconnect that replays subscriptions, a bundled REST and WebSocket server, Docker deployment, and two-step login with a one-time code. Default to upstream for the larger community and the documentation. Choose the fork only when one of those specific additions is the actual reason you are choosing a library at all.

API-Quotex — login hardened by a real browser

API-Quotex by A11ksa solves the failure mode that wastes the most hours: the login. Rather than scraping the sign-in form over HTTP and re-guessing it each time the platform changes, it drives Chromium through Playwright, extracts the session token, and caches it to a session file that later runs reuse until it expires. When it does expire, it refreshes it the same way.

The client itself is async and covers the full order lifecycle — place an order, subscribe to or iterate candles, resolve the outcome, read the balance — under an MIT license, and the repository marks itself stable.

The deciding trade-off is what it drags along. A Playwright-driven login means a Chromium install on whatever box the script runs on. On a laptop that is fine. On a slim container or a small VPS it is a real weight increase and one more thing to keep patched. The second consideration is upkeep: it has not been pushed since 2025, which for a wrapper of an unofficial interface is a longer gap than it sounds.

QuotexAPI — modern typing, still under construction

QuotexAPI by ChipaDevTeam is the one written the way you would write it today: async-first throughout, validated response models rather than raw dictionaries, and a service layer separating authentication, connection, account, trading and market data. It accepts either email and password or a session token, reconnects automatically, and ships under MIT with a permissive minimum Python version. If you are building something that other people will have to maintain, it is by some distance the most pleasant codebase here to read.

The deciding trade-off is candour about its own state. Its roadmap still lists implementing the actual endpoints, with parts of the surface running on mock data, and the project is young enough that the community has not shaken the bugs out for you. Treat it as a well-architected skeleton: verify every call you depend on against a demo balance before you trust its return value, and be ready to contribute the fix yourself when something is missing.

qxbroker (QuotexPy) — the only one you can pip install

qxbroker, published to PyPI as quotexpy, is the shortest path from zero to a working import: pip install quotexpy, then from quotexpy import Quotex. The client is async, takes a headless flag for its browser-backed login, and accepts a callback for the one-time code the platform emails during sign-in — a detail the others largely leave to you. It supports the usual set of operations, with the examples directory doing most of the documenting.

The deciding trade-off is silence. Its last push landed in early 2025, the longest gap of the four, and for software that tracks an interface which changes without notice that is the risk that matters most. There is a second wrinkle worth knowing: the PyPI page points at a repository path under a previous owner, which now redirects to the current one. Nothing sinister, but if you ever verify a package by eyeballing its homepage link, this is the case that teaches you to follow the redirect. Finally, LGPL-2.1 carries more obligations than MIT if you distribute a modified build — usually manageable, rarely free.

Companion tools worth knowing about

Not every job needs a full trading wrapper, and the surrounding ecosystem is where the roundups usually stop.

• Bulk candle history. The socket interface hands out a limited number of candles per request, which is fine for a live bot and useless for research. Purpose-built downloaders exist that page around that ceiling and write long OHLC histories to disk. If all you want is data to backtest against, one of these is a far smaller dependency than a full trading client. Read the license first: at least one of the popular ones ships with no license file at all, which legally means all rights reserved no matter how welcoming the README sounds.
• Bots built on top of a wrapper. Several public repositories are complete Telegram alert bots or strategy runners that import one of the libraries above. Their value to you is as reference implementations — how someone else structured reconnects, retries and rate limiting — not as software to run unread.
• Weekend and synthetic instruments. If your interest is the OTC market specifically, the symbol naming and availability rules differ enough from weekday instruments to be their own topic; the wrappers expose them, but discovering which are tradeable when is on you.

If you would rather not write any of this and are looking for ready-made Quotex trading bots that simply switch on, that is a different shopping list from this one — these are libraries, and a library is only a component of a binary options bot.

Which library fits your project?

The comparison table gives you the facts. This is the recommendation.

Said in one line each: pick pyquotex when you want the most-travelled road and real documentation; API-Quotex when authentication is the thing that keeps breaking and you can afford a browser on the host; QuotexAPI when code quality matters more to you than completeness and you are willing to finish it; qxbroker when the install has to be a single pip command and you accept owning the maintenance.

How to vet a Quotex library before you install it

Everything above is a snapshot. Unofficial wrappers get abandoned, platforms change their front end, and a repository that is the obvious answer today can be dead in six months — so the durable skill is the check, not the verdict.

Four of those are one command each, so there is no excuse for skipping them.

# 1. Is anyone still maintaining it?
curl -s https://api.github.com/repos/OWNER/REPO | grep -E '"(pushed_at|archived|open_issues_count|fork)"'

# 2. Is there a real license file? A 404 here means "all rights reserved".
curl -s -o /dev/null -w '%{http_code}\n' https://raw.githubusercontent.com/OWNER/REPO/main/LICENSE

# 3. Read what it does with your credentials before you run it.
git clone --depth 1 https://github.com/OWNER/REPO
grep -rnE 'requests\.(get|post)|httpx\.|urlopen|subprocess|eval\(' --include='*.py' REPO/

# 4. Install it somewhere disposable, never your system Python.
python -m venv .venv && . .venv/bin/activate

The credential check deserves a sentence of its own. A Quotex wrapper has exactly one legitimate reason to make an outbound request, and that is the platform itself. Analytics pings, telemetry to a developer's own host, or an unexplained POST buried in a login helper are all reasons to close the tab, whatever the star count says. Pair that with a kill switch in your own code, because a library that reconnects forever will also retry a bad decision forever.

Quick start: install pyquotex and read your balance

Enough evaluation. Here is the smallest thing that proves the whole chain works — install, authenticate, switch to the practice balance, print a number. If this runs, your environment is fine and every remaining problem is strategy rather than plumbing.

# pyquotex is not on PyPI - install it straight from the repository:
#   python -m pip install "git+https://github.com/cleitonleonel/pyquotex.git"
# or, with Poetry:
#   poetry add git+https://github.com/cleitonleonel/pyquotex.git

import asyncio

from pyquotex.stable_api import Quotex
from pyquotex.utils.account_type import AccountType


async def main():
    client = Quotex(
        email="[email protected]",
        password="put-it-in-an-env-var-not-here",
        lang="en",
    )

    await client.connect()

    # Switch to the practice balance BEFORE anything can place an order.
    await client.change_account(AccountType.DEMO)

    print("balance:", await client.get_balance())

    await client.close()


asyncio.run(main())

Three notes on that snippet. Keep the credentials in environment variables rather than in the file, because this script will end up in a repository eventually. The account switch belongs before any order logic, not after it, so a mistake in a later edit cannot reach a live balance. And the whole thing is a coroutine — if your existing project is synchronous, this is the point where you decide how the event loop is going to live inside it.

What comes next is deliberately not on this page: turning a connection into a strategy that decides when to send a CALL or PUT is a build guide of its own, and auto-trading an account well is mostly about the rules, not the transport. One thing worth doing before your first live order is arithmetic rather than code — work out the break-even win rate your payout implies, so you know what your script has to beat.

Already wired up a library? Pair it with a live signal feed

Notice what none of these four libraries gives you. They can log in, stream candles and fire an order in milliseconds, and not one of them has an opinion about what to trade or when. Execution is now the solved half of your problem; the decision is the open one, and building a Quotex trading bot around it is a much harder piece of software to write than a socket client.

That is the gap our live Binary Options signal feed fills. It publishes entries with a direction and reward-to-risk context, timestamped, in a structure you can read on the page or consume as the decision input your own script executes through whichever wrapper you just picked. Concretely: the feed says what and when, your client.trade(...) call says how much and where — the exact division of labour the libraries above leave open.

Be clear about what it is not. It is not a Quotex SDK and not an execution engine; it does not connect to your account or place anything for you, so you still need one of the libraries above to send the order. If you were hoping for a single package that both decides and executes, this is not that, and neither is anything else in this article. Historical and backtested results describe the past, never the next trade — the risk warning is worth two minutes before you automate anything.

The bottom line

For most people the answer is short: start with pyquotex, because it is the most used, the best documented and the only one in this comparison still receiving commits — and resolve its license question with the author before you build anything you intend to sell. Reach for API-Quotex the moment authentication becomes your recurring failure, take QuotexAPI if you would rather inherit clean architecture than finished features, and take qxbroker only when a one-line pip install genuinely outweighs the quietest repository of the four.

Then set a calendar reminder. Every verdict on this page is a description of some other developer's volunteer effort against an interface that owes it nothing, and the checklist above is the part that will still be true when this comparison is not.

FAQ

Does Quotex have an official Python API?

No public, sanctioned one. The broker maintains a GitHub organization account with no public repositories, and there is no published SDK or documented developer program behind it. Everything in this article is a community reverse-engineering of the interface the platform's own web client uses, which is exactly why maintenance status matters so much when you choose one.

Can Quotex restrict an account for using an unofficial library?

Your account is governed by the platform's terms, not by the license on a GitHub repository. Automating through an unofficial wrapper is a decision you make with that in mind, and it is a good reason to keep your automation modest, to test on a practice balance, and to avoid anything that hammers the platform with requests. No open-source license can grant you permission that only the broker can give.

Do I need Chromium installed to use these libraries?

Only for some of them. API-Quotex deliberately drives a real browser through Playwright to obtain a session token, so Chromium has to exist on the machine that runs it. Others sign in over HTTP or take a headless-browser flag. If you are deploying to a small container, treat that dependency as a selection criterion rather than an install detail you discover later.

Which one should I use if I only want historical candles?

None of the four full wrappers, most likely. The socket interface returns a limited window of candles per request, and dedicated downloader projects exist that page around that limit and write long histories to disk. That is a much smaller dependency for a research or backtesting workflow — just confirm the project carries a license before you build on it, because several of these small tools ship without one.

Are these libraries safe to use in a commercial product?

Read the license file rather than the README badge, and be aware they differ across this shortlist. Two are MIT, one is LGPL-2.1, and the most popular one currently ships a copyleft license file alongside permissive package metadata, which is not a question you want to answer by guessing. Separately, the license only covers the code — it says nothing about whether the broker permits the automation your product performs.

Sources & Further Reading

Want to go deeper? These independent, authoritative sources shaped this guide — each one is worth reading in full:

• Python asyncio documentation — the event-loop model every one of these wrappers is built on
• Python Packaging Authority tutorial on installing packages, including from a Git repository
• Choose a License — what it means when a repository ships no license file at all
• GitHub Docs on licensing a repository and how license detection works
• Playwright for Python documentation — the browser-automation dependency one of these libraries requires