Issues & requests

Report a bug or request a change. This board is public — you can see what others have raised and follow what we're working on.

#12Change requestIn progressSep 19, 2026
Mobile app publishing: TickerAll Terminal on Google Play and the iOS App Store
Goal Publish the TickerAll Terminal as a native mobile app on Google Play and the Apple App Store, alongside the direct Android APK that is already live at tickerall.com/download. The mobile terminal itself (quotes, charts, trade band, history, alerts, drawer) is already at MT5-mobile grade as a PWA; this issue tracks the store packaging and publishing work on top of it. Done so far - PWA polish for phones shipped to production: app-mode sign-in under /terminal, safe-area handling, 44px tap targets, landscape chart-only mode, first-run "connect a broker account" card, manifest with screenshots and shortcuts, lazy-loaded editor so first load is ~1.4 MB instead of 6.6 MB - Stream resume on wake/foreground/online, so the app recovers live data after the phone sleeps - In-app alerts via service-worker notifications while the app is open - Android: signed APK + AAB built (package com.tickerall.terminal, v1.0.1) with Digital Asset Links verified on tickerall.com, so the app opens full-screen with no browser bar - tickerall.com/download page with the APK, install steps, and "coming soon" placeholders for Google Play and the App Store - Play Store listing kit prepared: description, screenshots, feature graphic, icon - /terms page live (required by both stores) In progress / remaining 1. Google Play: create the developer account, upload the AAB, complete the store listing, data-safety form and the Financial-features declaration, closed testing, then production rollout 2. iOS: native shell around the terminal built via a macOS CI runner and TestFlight; App Store listing; address the App Review rules for trading and finance apps (the app is an account-management and charting client for the TickerAll API, execution happens at the user's broker). Fallback if review pushes back: read-only iOS build with trading via the web app 3. Push alerts while the app is closed (server-side push); the client side is built, the server side ships with an upcoming backend release 4. Replace the "coming soon" placeholders on /download with the store badges once each listing is live, and add smart app banners How to follow along The Android APK is available today at https://tickerall.com/download. Store listings will be linked from the same page when they go live.
by Miguel (TickerAll)
#11Change requestPlannedSep 19, 2026
Public Agent Skills repo for TickerAll (SKILL.md packs for Claude Code, Cursor and other coding agents)
Summary Ship first-party Agent Skills for TickerAll in a public repo so AI coding agents (Claude Code, Cursor, Codex, and any agent that reads SKILL.md folders) know how to build against TickerAll correctly, without pasting the docs into every session. Today an agent asked to "connect my MT5 account and stream ticks through TickerAll" has to discover the REST/WS surface, the auth model, the tier rules and the two SDKs from scratch, and usually guesses something wrong: base URL, auth header, checking status instead of hot, polling instead of the WS stream, server time vs UTC on candles. A skill fixes that once, for every agent. Where it lives A new PUBLIC repository (working name TickerAll/skills), MIT-licensed, alongside the public SDKs. Users clone it or copy a folder into their agent's skills directory. Nothing in it references anything below the public API surface, same rule as the SDK READMEs and the docs. Proposed skills (one folder each, SKILL.md with name + description frontmatter, optional references/ and scripts/) - tickerall-api: auth (Authorization: Bearer cf_api_*), base URL, account lifecycle (connect -> hot -> trade/read), error codes, tier limits, rate and idempotency conventions - tickerall-sdk-ts: @tickerall/sdk install and idiomatic usage: accounts, positions, place/close/modify, candles, history, WS tick stream with reconnect - tickerall-sdk-python: same for the tickerall PyPI package (sync + async) - tickerall-mcp: adding mcp.tickerall.com as a connector, the 15 tools, when to prefer MCP over the SDK - tickerall-market-data: candles (UTC timestamps vs terminal server time), tick stream, symbol specs, deep history - tickerall-trading: place/close/modify semantics, demo-vs-live checks, SL/TP on market orders, copy-trading basics, safe defaults tickerall-api is the minimum first cut; the rest can land incrementally. Deliverables 1. Create the public repo with license, README, CHANGELOG and CI that lints every SKILL.md and runs smoke scripts against staging with a CI-only key 2. One folder per skill above, grounded in the live docs and SDK source, with runnable snippets tested against staging 3. scripts/ helpers where useful (e.g. a smoke script that lists accounts and prints the first tick) 4. Install instructions per agent: Claude Code (~/.claude/skills/ or project .claude/skills/), Cursor rules, plain copy for other agents 5. Link from /docs and the homepage next to the MCP section ("Works with your AI coding agent") 6. Add the skills repo to the release checklist: an API change bumps @tickerall/sdk, the tickerall PyPI package, MCP, docs AND the skills Acceptance A fresh Claude Code session with the skills installed and only an API key can, without further prompting: connect a demo account, wait for hot, place and close a demo trade, fetch H1 candles with correct UTC handling, and stream ticks over WS. Why now The MCP server already dropped the integration bar for chat-style use. Skills do the same for code-writing agents, which is how most bot developers and platform builders actually work. A public skills repo is also a discovery surface on its own (GitHub search, agent skill directories).
by Miguel (TickerAll)
#9Change requestPlannedAug 15, 2026
TickerAll: Subscribe to restart events (broadcast on planned restarts)
Add a way for clients to be notified when TickerAll performs a planned restart or maintenance, so automated systems can react gracefully instead of only seeing their connection drop. Today, when a service is brought down for a deploy or restart, live broker sessions and streams drop and clients reconnect blind. Instead, let a client subscribe to a maintenance/restart event — delivered over the existing WebSocket stream and/or an outbound webhook. When TickerAll is about to bring a service down, broadcast the event to all subscribers, ideally with a short lead time and an estimated back-online window, so bots can pause new orders, optionally flatten, and prepare to reconnect. A follow-up all-clear event can fire once the service is back. Why: automated trading systems need a clean, deterministic signal to handle maintenance windows, rather than treating a planned restart the same as an unexpected disconnect. To scope: the event schema (type, scheduled time, reason, estimated duration), delivery channels (WebSocket event vs outbound webhook), lead time, and whether an all-clear event fires on recovery.
by TickerAll
#8Change requestDoneAug 15, 2026
TickerAll: TradingView alert-to-trade (webhook execution)
Let users connect a TradingView strategy or alert directly to their MT5 account through TickerAll — with no VPS or local bridge. TradingView alerts can only fire a webhook (a JSON POST to a URL). Add a per-user webhook endpoint on TickerAll that receives the alert payload and executes the matching order on the user's connected account: symbol, side (buy/sell), volume, and optionally stop-loss, take-profit, and order type. The user configures — in the dashboard — which account the webhook drives and how to read the payload fields. Why: connecting TradingView to MetaTrader is one of the most common pain points in retail algo trading, and existing solutions are fragile self-hosted bridges. TickerAll is hosted and already executes on MT5, so it is a natural fit: receive the alert, place the trade, report the result. To scope: the payload schema / field mapping, per-webhook authentication (a secret token), which order types to support first, optional server-side risk limits, and how fills are reported back to the user.
by TickerAll
#7Change requestPlannedAug 15, 2026
TickerAll: Stop-limit orders (buy & sell stop-limit)
TickerAll currently supports market, limit, and stop orders — but not stop-limit orders. Please add support for buy stop-limit and sell stop-limit order types. A stop-limit order combines a stop trigger with a limit price: when the market reaches the stop price, a limit order at the specified limit price is placed. This gives control over the fill price that a plain stop order (which fills at market once triggered) does not offer. This completes the standard pending-order set: limit, stop, and stop-limit.
by TickerAll
#6Change requestDoneAug 15, 2026
TickerAll: Copy trading
We're planning copy trading — automatically mirror trades from a master (leader) account to one or more follower accounts, all through the TickerAll API. This issue tracks the work; follow it for updates. Tell us how you'd use it — which brokers, the allocation model you'd want (fixed lot, proportional to balance/equity, or risk-based), and the controls that matter (per-follower risk caps, symbol filters, max drawdown, reverse-copy) — and we'll fold your input into the design.
by TickerAll💬 1
#5Change requestPlannedAug 14, 2026
TickerAll: Multi-language support for the dashboard and docs
Make the dashboard, the documentation, and on-screen messages available in more languages, so TickerAll is comfortable to use when English isn’t your first language. This also includes API messages for authenticated users. If there’s a language you’d like us to prioritise, let us know here.
#4Change requestDoneAug 14, 2026
TickerAll: Bulk operations: act on multiple accounts or orders in one request
Add batch endpoints so a single API call can act across several accounts or several orders at once — for example, read the state of all your connected accounts together, or place, modify, or close a group of orders in one request — instead of making one call at a time. This cuts round-trips and makes running a larger pool of accounts simpler and faster. If this would help you, tell us which operations you'd most want batched — reads, placing orders, closing or modifying positions, or connecting and disconnecting accounts — so we can prioritise the ones people actually need.