Trading Bot Dashboard with FastAPI | Toss Dev Journal #24

🌐 한국어로 보기

For readers outside Korea: this bot trades against Toss Securities, one of Korea’s major retail brokerages, through its Open API. Up until now, changing a single price target meant editing code and restarting the process. This phase fixes that with a proper trading bot dashboard.

Building the Trading Bot Dashboard (dashboard.py, db.py)

I added a new SQLite table, strategy_configs, holding symbol, buy target price, order quantity, and take-profit/stop-loss ratios. The dashboard runs on FastAPI, and I added python-multipart so the form submissions from the dashboard’s HTML page could be parsed. The API surface is small on purpose:

POST /api/strategies      # add or update a condition
DELETE /api/strategies/delete   # remove a condition

The design principle behind this trading bot dashboard: the database is the single source of truth. The dashboard only writes to it; the monitoring loop is the one that reads it back on its own schedule, so the web server and the trading engine stay loosely coupled.

Simulated Buy → Take-Profit/Stop-Loss Cycle

With DRY_RUN = True enforced throughout, I ran the full cycle on a placeholder symbol (Samsung Electronics, 005930): simulated buy on target price hit → live P/L tracking → simulated sell once +5% take-profit or -3% stop-loss triggered. Every sell writes a row to the trades table, visible right away in the dashboard. I repeated this with SK Hynix (000660) to confirm multiple symbols track state independently. All account details and P/L figures here are placeholders.

Refactoring Notifications into a Dual-Channel Module (notifier.py)

Notification logic that used to be scattered across auto_trader.py now lives in notifier.py, routed by severity:

• INFO → Telegram + DB log only
• WARNING / ERROR / CRITICAL → Telegram + email (SMTP), both

The module follows a best-effort principle: if Telegram times out or the SMTP server is down, the exception is swallowed and the monitoring engine or background scheduler keeps running regardless.

A Non-Destructive Security Check (security_check.py)

security_check.py verifies system safety without placing any real orders, built around patterns from the Python sqlite3 documentation. It checks:

• Whether .env exists and is properly listed in .gitignore
• The five safety brakes: DRY_RUN=True, TARGET_BUY_PRICE=1 KRW, MAX_ORDER_QUANTITY_PER_TRADE=10 shares, MAX_CUMULATIVE_LOSS_PCT=10%, and a hard block on the live order API
• OAuth2 token issuance, account linkage, and quote-API access, all verified without touching the order endpoint

Running the diagnostic against a live API token confirmed all five safety brakes were active and reporting correctly to the console.

130 Passing pytest Cases

The dashboard API, DB transactions, notification routing, and the security check logic are all covered — 130 pytest cases, all passing, including dedicated coverage for the new python-multipart form-handling path.

A trading bot dashboard works by storing trade conditions in SQLite and exposing them through a FastAPI endpoint, so price targets and take-profit/stop-loss ratios can be updated live from a browser without restarting the monitoring engine.

What’s Next

Next up: adding a live P/L chart to this trading bot dashboard, and scoping out whether multi-account support is worth building.

FAQ

Does a dashboard edit apply instantly?

Not instantly — it’s picked up on the next monitoring cycle when the engine re-reads the database. No restart required.

Can real money move while DRY_RUN is on?

No. With DRY_RUN=True, the actual order API call is physically blocked, so everything runs as a simulated trade.

Why is python-multipart needed?

FastAPI needs it to parse HTML form-data submissions — that’s how the dashboard’s condition form sends data.

Does the bot stop if a notification email fails?

No — notifier.py is best-effort, so an SMTP failure is absorbed and the monitoring engine keeps running.