AI Crypto Scanner - Bitcoin: the scores, and the market feeds under them

Two kinds of data sit inside this scanner, and they want very different handling. One kind is the app's own verdict: a numeric technical score per coin, a six-level bullish-to-bearish sentiment read, and a short summary line built from MACD breakouts, RSI levels and trend lines. The other kind is the commodity input underneath, OHLCV candles, funding rates and long/short ratios, which the app pulls from Binance and Coinbase before it scores anything. Tell us which of those two you actually need and the route almost picks itself.

The proprietary layer only exists behind the app, so reaching it means authorized protocol analysis of its backend. The input layer is published by the exchanges and can be reconstructed straight from source. Most jobs want a slice of both. Below is what the scanner holds, how we reach each part, and what we hand over.

Where the numbers live inside the app

Each row below is a surface the app's own description names. The granularity column is what an integrator gets per record; the last column is the typical reason to want it.

Routes to that data, and the one we would take

Three routes genuinely apply here. They are not ranked; they answer different questions.

Route A — protocol analysis of the app backend

This is the only way to reach the app's own output: the technical score, the six-level sentiment, the scan matches and the summary text. We observe the authorized traffic between the app and its backend, map the login and token-refresh flow, then reconstruct the scan call and parse its response into clean records. Effort is moderate. Durability depends on the app's release cadence, which the store listing shows is occasional rather than weekly, so a refresh is rare and cheap. Access is arranged with you during onboarding, against a consenting account.

Route B — reconstruct the exchange feeds directly

The inputs under the scores, funding rates, long/short ratios, candles, are published by Binance and Coinbase on documented market-data endpoints. We pull them straight from source, skipping the app entirely. This is the most durable path because the exchanges version those endpoints and publish change notes. It is the right choice when you need the raw series and not the app's interpretation.

Route C — user-consented account access

Per-user state, saved scan conditions, alert thresholds, watchlists, sits behind the account. With the account holder's consent we reach it through the same authenticated session the app uses, and we keep a consent record for it. This route only matters when you are syncing a specific user's setup, not market-wide data.

For most briefs the honest answer is split: if you want the app's verdict, Route A is the only one that carries the score and the sentiment, so that is where we start; if you only need clean funding and positioning series, Route B is steadier because Binance and Coinbase maintain those endpoints publicly and we are not riding the app's release cycle at all. Route C joins in only when a named user's saved rules are part of the job.

A scan request, end to end

Illustrative shape, not a transcript. Endpoint paths and field names are confirmed during the build, not lifted from any published doc; the exchange calls are the documented ones cited at the foot of the page.

# Route A: the app's own scan + scoring
POST https://<scanner-backend>/v2/auth
  { "device_id": "...", "locale": "en" }
  -> 200 { "access_token": "ey...", "expires_in": 3600 }   # refresh before expiry

POST https://<scanner-backend>/v2/scan
  Authorization: Bearer ey...
  { "market": "spot",
    "filters": { "rsi": "<30", "macd": "bullish_cross",
                 "ma": "golden_cross", "bollinger": "lower_break" } }
  -> 200 {
    "matches": [
      { "symbol": "BTCUSDT",
        "technical_score": 78,          # app's own AI score
        "sentiment": "Very Bullish",    # one of six categorical levels
        "summary": "MACD breakout, RSI 28" }
    ] }

# Route B: pull the inputs straight from the exchange instead
GET https://fapi.binance.com/futures/data/globalLongShortAccountRatio
      ?symbol=BTCUSDT&period=1h        # ~30 days retained, per Binance docs
GET https://fapi.binance.com/fapi/v1/fundingRate?symbol=BTCUSDT
# Coinbase public candles throttle at 3 req/s, burst 6 -> 429; collector backs off.
      

The token has a short life, so the client refreshes ahead of expires_in rather than waiting for a 401. On the exchange side the only real friction is throttling, which the collector absorbs with backoff and retry.

What lands in your repo

Everything is tied to the surfaces above, not a generic checklist.

• An OpenAPI description of the scan and sentiment surfaces as we reconstruct them, plus the exchange calls used for inputs.
• A protocol and auth-flow report: the login, the bearer-token chain, refresh timing, and how the scan filters map to the UI conditions.
• Runnable source for the key endpoints in Python or Node.js, a collector that fetches scores and sentiment and a separate one for the exchange feeds.
• A normalizer that turns the six sentiment labels into a stable numeric scale and tags every field by origin (app verdict vs exchange data).
• Automated tests against recorded responses, so a field move shows up as a red test rather than a silent gap.
• Interface documentation and data-retention guidance covering what is kept, for how long, and under what consent.

What we plan around when we build this

Three things about this specific app shape the build, and we handle each rather than handing it back to you.

• The value is a derived score, so we keep the proprietary scoring strictly separate from the commodity inputs. We capture the score as the app emits it and never try to reverse the AI weighting, which keeps the deliverable honest about what is the app's judgment and what is plain exchange data.
• Binance retains only about 30 days of long/short series per its market-data docs, and Coinbase public endpoints cap at 3 requests per second per its rate-limit docs. We build the collector with backoff and a rolling backfill harness so historical sentiment is not lost to retention windows or 429s.
• The sentiment is a categorical enum, not a number. We pin the exact set the app uses, in the style of Very Bullish down to Slightly Bearish, and map it to a numeric scale, so a later release that rewords a label does not quietly shift your downstream logic. We also keep a schema-diff check that flags when an app update moves fields.

Consent and PIPA, where it actually bites

This is not a bank-account case, so account-aggregation regimes do not apply. The dependable basis is straightforward authorization from the account holder or, for the input layer, the exchanges' own public market-data terms. Where personal data does enter, through Route C's per-user alert configs and watchlists, South Korea's Personal Information Protection Act governs it, since JejuLeadSoft is a Korean developer. Korea's 2025 PIPA updates added a data-portability right from March 13, 2025, letting an individual request transfer of their personal data in a machine-readable format, which lines up cleanly with consented account access. Market data carries no personal information, so it sits outside that scope. We work authorized and logged, minimize what we collect to the fields you asked for, keep consent records for the account route, and sign an NDA where the work touches anything sensitive.

Keeping the scores fresh

Scores and sentiment are only useful while current. The collector runs on a schedule you set, refreshes its token ahead of expiry, and records a fetch timestamp on every record so stale reads are obvious. For the exchange layer we respect the published rate limits and stagger requests across symbols, and the backfill harness fills any gap left by an outage or a throttled window. If a release changes a payload, the schema-diff check raises it before bad data flows downstream.

Cost and how the build runs

The scan-and-sentiment collector ships as runnable source you own outright. Source-code delivery starts at $300, billed only after we hand it over and you confirm it pulls what you need. If you would rather not host anything, the same integration runs as our pay-per-call hosted API, where you call our endpoint and pay per call with nothing up front. Either way the build runs on a one-to-two-week cycle. Send us the app and what you want out of its data at /contact.html and we will scope it.

Screens we worked from

Store screenshots used while mapping the surfaces above. Tap to enlarge.

Where it sits among other scanners

If you are unifying signal data across several tools, these neighbours come up. Names are listed for context, not ranked.

• TradingView keeps a crypto screener over tens of thousands of pairs with filters on price, volume and technical rating, and exposes alerts on those conditions.
• Coinglass holds derivatives data, open interest, funding rates and liquidation heatmaps, much like the futures layer feeding this app's sentiment.
• CoinMarketCap stores broad listing, price and volume data across coins and exchanges.
• CoinGecko carries similar market data plus exchange and developer metrics.
• DEX Screener tracks on-chain pair data for tokens trading on decentralized exchanges.
• CryptoScreener247 runs RSI, MACD, EMA, volume and Bollinger screens with email alerts.
• altFINS publishes screeners, chart-pattern detection and signal lists for crypto.
• Crypto Base Scanner flags accumulation bases and pushes signals to trading bots.
• CoinScreener generates AI trading signals and market insight feeds.
• CryptoMeter offers an AI screener with buy and sell alert outputs.

Questions integrators actually ask

Can you separate the app's own AI score from the raw exchange data feeding it?

Yes. The technical score and the six-level sentiment read are the app's own output; the OHLCV, funding rates and long/short ratios beneath them come from Binance and Coinbase. We label every field by origin so you know which numbers are JejuLeadSoft's judgment and which are exchange data you could pull yourself.

If I only want funding rates and long/short ratios, is the app even needed?

No. Those series are published by Binance and Coinbase on documented market-data endpoints, so we reconstruct them directly without touching the app. The app earns its place when you want its scoring and its bullish-to-bearish classification, which exist nowhere else.

Does the six-level sentiment arrive as text or as a number?

It is a categorical label, in the style of Very Bullish through Slightly Bearish. We pin the exact set the app uses and map it onto a stable numeric scale, so a wording change in a later release does not break your downstream logic.

How do you keep the scan feed working after a JejuLeadSoft app update?

We keep a schema-diff check that flags when a release moves or renames fields, and fold the fix into maintenance so a refresh does not quietly break the feed. The store listing shows updates landing roughly yearly, so churn is manageable.

What we checked

We read the app's own Google Play description for its surfaces and feature names, cross-checked the futures inputs against Binance's market-data documentation, confirmed the Coinbase throttle figures against Coinbase's Exchange rate-limit docs, and grounded the privacy posture in Korea's 2025 PIPA updates. Specific sources opened:

• AI Crypto Scanner - Bitcoin on Google Play
• Binance USDS-M Futures: Long/Short Ratio endpoint
• Coinbase Exchange REST rate limits
• South Korea PIPA overview and 2025 updates

Interface mapping by OpenBanking Studio's integration desk, checked 15 June 2026.