DEV Community: wang vball

Day Trading vs Settlement: Same-Day US Stock Trades Do Not Mean T+0 Settlement

wang vball — Sat, 14 Nov 2026 23:24:36 +0000

Can you buy and sell a US stock on the same day, and does that mean it settles immediately? Same-day trading can be possible under applicable account rules, but most ordinary US stock transactions use T+1 settlement. Keeping trade date, expected settlement date and confirmed settlement status separate prevents a trading interface from presenting an executed sale as already settled cash.

A same-day purchase and sale describe when two trades happen. Settlement describes when the resulting obligations are completed. Calling both processes “T+0” hides a distinction that matters to investors and to the software displaying their accounts.

For ordinary US stock transactions covered by the standard cycle, the settlement convention is T+1, not T+0. That does not mean every investor must hold a stock overnight. It means same-day trading permission and settlement timing are different questions. Neither a quote feed nor a successful order submission answers both.

What does the T actually measure?

In settlement notation, T is the trade date. T+1 means one business day after that date; T+0 would mean settlement on the trade date. Execution time is more precise: it records when an order, or part of an order, was filled. A trade date is a business label, not simply the date shown on the viewer's laptop.

The SEC's T+1 transition FAQ identifies May 28, 2024 as the compliance date for the shortened standard cycle. Its guidance also describes exceptions and limited circumstances involving expressly agreed settlement terms. The useful statement is therefore “most ordinary US stock transactions settle on T+1,” not “every security settles tomorrow.”

Imagine a hypothetical purchase and sale on the same Monday, with Tuesday an ordinary applicable business day. The trades occur on Monday, while their expected standard settlement date can be Tuesday. Closing the position does not turn Monday into the settlement date. This illustration assumes an ordinary transaction and no intervening holiday; it is not a calendar or account-eligibility calculation.

Illustration of ordinary T+1 transactions. Instrument-specific terms and applicable business calendars still matter.

Does “same-day trading” mean unlimited trading?

No. It describes timing, not permission. Whether an account can enter a transaction depends on its funding, type, restrictions and the broker's current controls.

FINRA's current cash-account guidance says securities must be fully paid for before they are sold. For intraday purchases and sales, it emphasizes using settled funds at purchase. It also distinguishes a good-faith violation involving unsettled sale proceeds from free-riding. A screen that shows sale proceeds is not, by itself, proof that those proceeds are settled and available for every subsequent use.

Margin accounts follow a different framework. FINRA adopted new intraday margin requirements effective June 4, 2026, with a permitted broker transition period through October 20, 2027. During that transition, generic summaries of historical pattern-day-trader rules are not a reliable substitute for checking the rules a particular broker applies. This article does not calculate buying power or determine whether an account may trade.

Frequent trading carries financial risk, and margin can increase losses beyond the original deposit. The distinction explained here is educational, not a recommendation to trade more often or a way to avoid account restrictions.

Market data is not your settlement record

A market-data message tells you about the market. A broker execution report tells you about your fills. A settlement record tells you the broker-reported state of the resulting obligations. These sources answer different questions even when their timestamps look similar.

TickDB's documented US-stock market data is useful for displaying prices and observing market activity. Its ticker documentation includes a market-data timestamp and conditionally available quote fields. Those fields should not be interpreted as proof that your account bought a security, that an order was filled, or that funds have settled.

For a portfolio interface, keep the price panel separate from the order and cash ledger. A fresh TickDB quote can update valuation without changing an execution or settlement flag. Likewise, a broker's execution notification should not automatically change a pending-settlement balance into a settled balance.

A quote timestamp is not a settlement confirmation. This is an information-model illustration, not a screenshot of a broker system.

A small state model that avoids the shortcut

The following Python example keeps three facts separate: trade date, an externally supplied expected settlement date, and a confirmation flag. All records are fabricated. The dates are inputs, not a calculation of US holidays or settlement eligibility.

from dataclasses import dataclass
from datetime import date

@dataclass(frozen=True)
class TradeRecord:
    trade_id: str
    trade_date: date
    expected_settlement_date: date | None
    settlement_confirmed: bool = False

    def display_status(self):
        if self.settlement_confirmed:
            return "Broker reported settled"
        if self.expected_settlement_date is None:
            return "Settlement date unknown"
        return f"Expected {self.expected_settlement_date}; not confirmed"

# Fabricated records; dates are supplied, never calculated here.
buy = TradeRecord("BUY-1", date(2026, 11, 16), date(2026, 11, 17))
sell = TradeRecord("SELL-1", date(2026, 11, 16), date(2026, 11, 17))
assert buy.trade_date == sell.trade_date
assert not buy.settlement_confirmed and not sell.settlement_confirmed
assert "not confirmed" in sell.display_status()
unknown = TradeRecord("UNKNOWN-1", date(2026, 11, 16), None)
assert unknown.display_status() == "Settlement date unknown"
confirmed = TradeRecord("DONE-1", date(2026, 11, 16),
                        date(2026, 11, 17), True)
assert confirmed.display_status() == "Broker reported settled"
print(buy.display_status())
print(sell.display_status())

The local example prints the same expected date for both trades, with “not confirmed” attached to each. It also checks an unknown-date case and an explicitly confirmed case. A same-day round trip does not set either confirmation flag.

This is deliberately not a brokerage integration. In production, only a validated, appropriately matched broker event should change the confirmation state. Store the source, event identifier and update time so that the interface can explain why it changed. Preserve corrections rather than treating the first notification as permanent truth.

Do not replace a missing expected date with “today plus one day.” Weekends are not the only calendar issue, and instrument terms can matter. Do not use the current wall clock passing an expected date as proof of completion either: expected and confirmed remain separate states. If a source is delayed, show that uncertainty instead of manufacturing a settled status.

What should the interface actually say?

Prefer narrow labels such as “order filled,” “expected settlement date,” “settlement pending,” and “broker reported settled.” Avoid one green “complete” badge that conflates execution, position closure, cash availability and settlement.

When explaining a rejection or cash restriction, use the broker's current response and account records, not an inference from the market-data timestamp. When explaining T+1, name the applicable scope and distinguish business days from calendar days. If the needed confirmation is unavailable, “unknown” is more accurate than a confident date-derived answer.

The practical answer to the original question is simple: same-day US stock trading does not establish same-day settlement. Treat trading permission, execution and settlement as separate facts, and require the right evidence for each.

Official materials checked November 15, 2026: SEC T+1 FAQ, FINRA Frequent Intraday Trading and New Intraday Margin Requirements, and TickDB ticker documentation. The code and diagrams are educational examples, not live account tests or investment advice.

Choosing a Futures Tick Database: Test Event Fidelity Before Query Speed

wang vball — Fri, 13 Nov 2026 23:16:48 +0000

Which database is best for futures tick data? Choose one that preserves the events your application needs before comparing query speed. Two trades can share a timestamp, continuous symbols can change their underlying contracts, and database deduplication rules differ. A small synthetic replay test can expose these mistakes before a fast query turns them into plausible but incorrect results.

For trade analytics, start with a trustworthy trade-event archive and a database whose duplicate and correction handling you can verify. For order-book reconstruction, trade records alone are insufficient: you also need the relevant book events and recovery rules. A fast database cannot reconstruct events that its upstream feed never supplied.

This is an evaluation method, not a database speed ranking or a claim that one market-data service covers every futures venue.

Separate the feed from the database

A market-data API delivers a documented representation of the market. A raw event log preserves what your collector received. A query database organizes that material for analysis. These responsibilities can share infrastructure, but they should have separate acceptance criteria.

TickDB is a useful example of the first layer. Its current documentation describes REST and WebSocket trade data for China and Hong Kong futures. That establishes a documented data-source option for those markets; it does not establish a user-queryable SQL database, exchange-native packet capture, or complete historical replay.

Preserve the original message, source, receive time and a durable collector receipt identifier before normalization. Keep source event time separately, with its documented unit and meaning. Receipt order can reproduce what your collector observed; sorting by event time answers a different question. Neither ordering should silently replace the other.

Suggested architecture: delivery, preservation and analytical queries are separate responsibilities, not a vendor architecture diagram.

Decide what identifies a futures event

A symbol plus a millisecond timestamp is not a universal event key. Two genuine trades can arrive with the same timestamp and price. Collapsing them can undercount volume while leaving a chart looking reasonable.

Use a documented event identifier within its documented scope when one exists. That scope may require a source, venue, session and instrument. Do not assume an ID is globally unique or survives a session reset. If the source provides no reliable identifier, preserve separate receipts and mark identity unresolved instead of silently deleting apparent duplicates.

The distinction matters when adapting TickDB messages. Its WebSocket documentation specifies single-trade objects for China and Hong Kong futures, and explicitly lists a trade ID for Hong Kong futures. The China futures example does not establish the same identifier guarantee. One universal adapter that assumes every message has an ID would overstate the documented contract.

Two events can share a timestamp. This synthetic example illustrates identity, not measured exchange traffic.

Contract identity needs the same care. Store the concrete contract and the effective mapping of any continuous alias separately. TickDB's data specification distinguishes regular China futures contracts from continuous symbols intended for market tracking, not delivery. Do not treat a continuous series as one permanent tradable contract. Record the roll rule and any price adjustment before comparing results across a rollover.

Test the projection without destroying the evidence

Keep the raw deliveries immutable and build a separate analytical projection. The following standard-library Python example uses a deliberately synthetic schema. It assumes source-defined IDs scoped by source, session and contract, plus explicitly ordered revision numbers. Those are test assumptions, not fields promised by every provider.

The seven deliveries include two trades at the same time, a repeated delivery, a correction, a late older revision and two receipts without IDs. The projection retains both identified trades, applies the correction, and leaves the unidentified receipts unresolved.

def project(events):
    """Synthetic schema: IDs and revision order are source-defined."""
    latest, unresolved = {}, []
    for event in events:
        row = dict(event)
        if row.get("event_id") is None:
            unresolved.append(row)  # Never guess identity from time/price.
            continue
        key = tuple(row[k] for k in
                    ("source", "session", "contract", "event_id"))
        old = latest.get(key)
        if old is None or row["revision"] > old["revision"]:
            latest[key] = row
        elif row["revision"] == old["revision"]:
            payload = lambda r: {k: v for k, v in r.items()
                                 if k != "receipt_id"}
            if payload(row) != payload(old):
                raise ValueError("Conflicting payload at the same revision")
    return list(latest.values()), unresolved


def example():
    base = dict(source="synthetic", session="S1", contract="FUT-A",
                event_ms=1000, price="100.00", revision=1)
    a = dict(base, event_id="A", receipt_id=1)
    b = dict(base, event_id="B", receipt_id=2)
    deliveries = [a, b, dict(a, receipt_id=3),
                  dict(a, revision=2, price="100.25", receipt_id=4),
                  dict(a, receipt_id=5),
                  dict(base, event_id=None, receipt_id=6),
                  dict(base, event_id=None, receipt_id=7)]
    resolved, unresolved = project(deliveries)
    assert len(resolved) == 2 and len(unresolved) == 2
    assert next(r for r in resolved if r["event_id"] == "A")["price"] == "100.25"
    print("7 deliveries: 2 resolved events, 2 unresolved receipts")


if __name__ == "__main__":
    example()

The local synthetic run prints 7 deliveries: 2 resolved events, 2 unresolved receipts. It does not prove market completeness, throughput or database durability. The unresolved receipts may include duplicates; retaining them avoids making an unsupported identity decision. Do not aggregate them as confirmed distinct trades without further reconciliation.

A changed payload at the same revision raises an error rather than silently picking a winner. Production ingestion should quarantine that conflict while retaining its raw message. This example does not implement cancellations, persistent checkpoints or a source-specific sequence protocol. Add those cases according to the feed contract, including sequence resets and recovery after a collector restart.

Compare duplicate semantics before performance

QuestDB and ClickHouse illustrate why “supports deduplication” is not a sufficient selection criterion.

QuestDB's current deduplication documentation describes explicit key columns, including the designated timestamp, for WAL tables. Its UPSERT mode keeps the latest write for matching keys. That is write order, not necessarily the highest source revision: a late old correction needs deliberate handling. Enabling deduplication also does not clean up pre-existing duplicates retroactively.

ClickHouse ReplacingMergeTree identifies duplicates through the sorting key and removes them during background merges whose timing is not guaranteed. A query cannot assume those merges have already completed. Evaluate query-time replacement semantics, including FINAL where appropriate, and measure the actual query shape you will use.

Neither behavior is inherently the right answer for every workload. An immutable audit archive and a latest-corrected analytical view have different requirements. Feed the same test deliveries into each candidate and compare the results immediately after ingestion, after maintenance, and after replay. Check contract separation, retained revisions and unresolved records, not just the final row count.

Benchmark only the candidates that preserve meaning

Once the semantic tests pass, measure your real workload: sustained ingestion, late arrivals, narrow contract-and-time queries, broader aggregates, and recovery. Hold the input dataset, hardware, retention policy and query results constant. Report cold and warm query behavior, concurrency and storage usage rather than publishing a single unexplained latency number.

Validate backfill separately. TickDB's documented REST trades endpoint accepts a symbol and a limit of up to 1,000 records; that alone does not demonstrate arbitrary time-range recovery or lossless polling. Ask what can be recovered after a longer outage, and test the exact boundary. Storage and redistribution rights also need separate confirmation.

Choose the simplest system that passes these checks at your required scale. If a candidate cannot explain which events survived replay, a faster query is answering an uncertain question.

Documentation checked November 14, 2026: TickDB Data Specification and Trade documentation; QuestDB Deduplication; ClickHouse ReplacingMergeTree. Code results are synthetic local validation, not a provider benchmark.

Can You Use a Real-Time Forex API for Free? A Trial Has Limits

wang vball — Thu, 12 Nov 2026 23:19:23 +0000

A free forex API can be useful for evaluating live quotes, but “free” does not necessarily mean ongoing access for a production application. Check the trial expiry, permitted currency pairs, request and subscription budgets, historical access, and usage rights separately. TickDB provides a concrete example: its documented Free plan is a seven-day trial, not an unlimited free production tier.

The useful question is not just whether an API returns EURUSD. It is whether the access you can test today covers the application you intend to operate next month. A prototype that retrieves one quote can succeed even when a multi-user dashboard would exceed a connection limit, need an unavailable pair, or require historical queries outside the plan.

This article uses TickDB's public documentation, checked on November 13, 2026, to show how to make that decision. It is not a provider ranking or a live performance benchmark. The same evaluation questions can be applied to another supplier, but the numerical limits below belong to TickDB.

A free trial is a time-limited evaluation

TickDB's Pricing documentation lists a seven-day Free trial with selected symbols, five concurrent subscriptions, one WebSocket connection, and an API rate limit of 30 requests per minute. It includes real-time quotes and real-time candlesticks. Those are separate constraints: access to the quote endpoint does not establish that every currency pair is included, and one open connection does not imply unlimited subscriptions.

Start by writing down the exact pairs and data your prototype needs. A currency converter using occasional snapshots has a different workload from a streaming dashboard. Test those specific symbols with the actual evaluation account rather than assuming that a supported-market list is the same as an account's entitlement list.

For a permanent free tier, the evidence must explicitly establish continuing access after the trial period. The documented seven-day trial does not do that. An application intended to run indefinitely therefore needs a plan for what happens when evaluation access ends, even if its traffic is small.

Separate request volume from streaming capacity

REST requests, open WebSocket connections, and concurrent subscriptions measure different activity. Reducing polling can lower REST traffic without changing how many symbols remain subscribed. Combining updates on one connection can reduce the connection count without reducing the subscription count.

Consider an illustrative workload, not a measured service result. Polling one batched snapshot every two seconds produces 30 requests per minute. That reaches the documented Free request limit before allowing for any other calls. Polling every three seconds produces 20 requests per minute, leaving ten requests of arithmetic headroom, but it does not prove the server will accept a burst or that other applications sharing the key are idle. A rate limit is not a recommended target operating level.

The Ticker Snapshot documentation allows up to 50 symbols per request. That endpoint maximum is not a grant of access to 50 trial symbols. Batch only symbols the account can actually access, and budget all calls sharing the relevant allowance. For a streaming implementation, verify connection and subscription limits independently instead of treating “WebSocket supported” as the end of the check.

Figure 1. An evaluation checklist, not a measured benchmark or a guarantee of account access.

Candlestick access does not promise arbitrary history

A common surprise is that a plan can expose candlesticks while restricting time-range queries. TickDB's Candlestick Data documentation says that the Free plan can query candlesticks but cannot specify a range using start_time or end_time.

That distinction matters when a prototype becomes a backtest. A chart showing currently available bars is not evidence that the same account can retrieve the last year for every pair. The pricing page lists historical data separately, while the endpoint documentation describes the exact parameter restriction. Read both before deciding whether a free evaluation can answer your research question.

Make the historical requirement explicit: pairs, interval, requested date range, and any completeness checks. If a query mode is unavailable, preserve that result. Removing the dates until the endpoint returns something may help diagnose the issue, but it changes the question and cannot validate the original backtest requirement. Also account for the last returned candle still forming; its changing values are not automatically a data error.

Make access failures visible in the integration

A failed request should tell you whether to change the workload, check permissions, or investigate transport. Repeating a forbidden request does not create permission. TickDB documents 3001 as a rate-limit error, 3006 as product access unavailable on the current plan, 3008 as unavailable candlestick time-range queries, and 3009 as an endpoint permission problem.

The following Python example makes one snapshot request and records a useful failure category. It requires the third-party requests package and an API key supplied through the TICKDB_API_KEY environment variable. Run it on a trusted backend, not in a public browser bundle. It is an implementation example based on the documented contract; no live account or market-data performance was tested for this article.

import os
import requests


def fetch_forex_snapshot(symbol="EURUSD"):
    response = requests.get(
        "https://api.tickdb.ai/v1/market/ticker",
        params={"symbols": symbol, "type": "forex"},
        headers={"X-API-Key": os.environ["TICKDB_API_KEY"]},
        timeout=10,
    )
    try:
        body = response.json()
    except ValueError as exc:
        raise RuntimeError(
            f"HTTP {response.status_code}: non-JSON response"
        ) from exc
    if not isinstance(body, dict):
        raise RuntimeError("Unexpected response shape")

    code = str(body.get("code", "UNKNOWN"))
    if not response.ok or code != "0":
        if code == "3001":
            retry_after = response.headers.get("Retry-After")
            action = f"Rate limited; Retry-After={retry_after!r}"
        elif code in {"3006", "3008", "3009"}:
            action = "Check product, query-mode, or endpoint access"
        else:
            action = "Inspect the documented error before retrying"
        raise RuntimeError(
            f"HTTP {response.status_code}, code={code}: {action}"
        )

    rows = body.get("data")
    if not isinstance(rows, list) or not rows:
        raise RuntimeError("No usable snapshot returned")
    return rows

The code checks both the HTTP outcome and the business code, normalizing the latter because error codes can be strings or integers. It deliberately performs no automatic retry. A production caller should honor the documented rate-limit wait, use bounded retries for transient failures, and stop on permission failures until the request or account changes. Connection exceptions and timeouts also need handling at that caller boundary.

A successful response is still only one piece of evidence. Inspect the requested symbol, its timestamp, and the fields your application uses. The ticker documentation makes fields such as bid and ask conditional on availability; a generic response schema is not proof that every forex instrument returns them. Do not invent missing values simply to make a comparison screen complete.

Figure 2. Proposed failure handling. Different failure causes require different next actions.

Choose paid access from requirements rather than the largest number

The public monthly pricing lists Starter at $99 per month, Professional at $299, and Enterprise at $899. Their documented API limits are 60, 600, and 1,800 requests per minute respectively, with one, three, and ten WebSocket connections. These figures describe monthly plans as checked on November 13, 2026; other billing periods and later pricing changes should be verified separately.

Those numbers are useful only after you know the binding constraint. A higher request allowance may solve polling pressure but not an unsupported field or an unsuitable data license. Likewise, a larger historical allowance does not by itself establish the coverage or quality needed by a particular strategy. Ask the provider to resolve any market-specific ambiguity before treating a general pricing table as a production promise.

Public display, redistribution, storage, and commercial use also require their own rights check. The technical access facts above do not establish those permissions. Obtain the terms applicable to your intended use rather than inferring them from a working key or a paid price.

The decision a free evaluation should produce

Finish the trial with a short acceptance record: which pairs worked, which data and date ranges were available, the workload you tested, failures observed, the expected paid configuration, and unresolved usage rights. Keep documented limits separate from measurements you actually made.

A free forex API is enough for an evaluation when it lets you answer those questions within its time and access limits. It is enough for ongoing production only when the continuing plan, workload, market coverage, and rights all support that use. If one remains unverified, the honest result is an open requirement, not a claim that the integration is ready.

Choose a Stock API by Verifying Instrument Identity Before Comparing Prices

wang vball — Thu, 12 Nov 2026 00:02:28 +0000

A stock API can return a valid price for the wrong instrument if an integration treats a ticker as a universal identifier. Compare providers on their ability to resolve the requested instrument, retain exchange and currency context, and reject ambiguous mappings before scoring speed or cost. A small identity contract and deliberately conflicting test fixtures make these differences visible without pretending that a successful request proves historical coverage or entitlement.

Resolve the instrument before trusting its price

For a multi-market watchlist, the first acceptance question is whether each response belongs to the security the user selected. A ticker string alone is not a complete identity contract. A market suffix can help distinguish a provider's symbol namespace, but it should not be silently treated as a globally stable instrument identifier.

Store the provider's exact symbol alongside the expected market or exchange and currency. Keep a separate application identifier so that switching providers does not require rewriting every watchlist, alert and historical row. This is an integration design recommendation, not a claim that a particular provider guarantees permanent identifiers.

The difference matters when a mapping is incomplete. A request that returns HTTP success can still be unusable if the integration cannot establish which instrument it received. A blank currency must remain unknown; filling it with a convenient default turns missing evidence into a false assertion.

Make providers answer the same identity questions

Start with a small, documented basket representing the instruments your application actually supports. Include ordinary symbols, similarly named instruments across markets, malformed requests, and known historical changes if those changes matter to your product. Do not manufacture a claim that a real ticker changed merely to populate the test.

For every candidate, record its exact request symbol, returned symbol, exchange field, currency field, and behavior when the symbol is ambiguous or unsupported. Distinguish an explicit error from an empty result and from a successful response with missing metadata. All three require different handling in your adapter.

TickDB's stock-information documentation gives a concrete example of this contract. It lists symbols such as AAPL.US and 700.HK, describes exchange and currency fields, and documents an optional product type for disambiguation after an AMBIGUOUS_SYMBOL error. It also states that conditional fields may be omitted when data is unavailable. These are documentation statements checked on November 12, 2026, not results from a live account test.

Those details provide a starting point for an adapter. They do not establish that the endpoint supplies historical identifier mappings, delisted universes, or point-in-time metadata. If a backtest depends on those features, obtain separate evidence rather than inferring them from a current stock-information response.

Use a contract that fails visibly

The following Python example validates already-normalized metadata. Its field names belong to the example adapter, not to a claimed universal provider schema. Map each provider's documented fields explicitly before calling the validator. In particular, normalize exchange codes using a reviewed mapping rather than equating a market suffix with an exchange.

from dataclasses import dataclass

@dataclass(frozen=True)
class Expected:
    provider_symbol: str
    exchange: str
    currency: str

def identity_errors(expected, row):
    required = {
        "provider_symbol": expected.provider_symbol,
        "exchange": expected.exchange,
        "currency": expected.currency,
    }
    errors = []
    for field, wanted in required.items():
        actual = row.get(field)
        if actual is None or actual == "":
            errors.append(f"{field}: missing")
        elif actual != wanted:
            errors.append(f"{field}: expected {wanted}, got {actual}")
    return errors

expected = Expected("EXAMPLE.US", "EXAMPLE_EXCHANGE", "USD")
good = {"provider_symbol": "EXAMPLE.US",
        "exchange": "EXAMPLE_EXCHANGE", "currency": "USD"}
assert identity_errors(expected, good) == []
assert identity_errors(expected, {**good, "currency": "HKD"})
assert identity_errors(expected, {**good, "exchange": None})
assert identity_errors(expected, {**good, "provider_symbol": "EXAMPLE.HK"})
print("4 synthetic identity checks passed")

The fixture names are deliberately synthetic. The code checks the validator, not a supplier's accuracy. For a live acceptance run, preserve the raw response and the normalization version so a rejected row can be traced back to its source. Quarantine mismatches instead of silently attaching them to an existing chart.

Exact comparison is useful only after normalization is defined. If one provider names an exchange differently, that is not automatically incorrect data. Review the mapping against documentation, version it, and then compare normalized values. Do not remove punctuation or suffixes broadly just to make a test pass.

Separate current identity from historical continuity

A current symbol list answers what the service recognizes now. A historical research workflow may need to know what was recognized on a past date, which symbol applied then, and whether the data universe contains instruments that later disappeared. These are different requirements.

For a current-price widget, explicit symbol resolution and missing-field handling may be sufficient. For a historical portfolio simulation, make dated mappings and universe coverage contractual acceptance items. Ask for a documented example spanning a real change and retain the evidence. If that evidence is unavailable, mark the requirement unresolved; do not award a passing score simply because today's quote works.

The same boundary applies when evaluating TickDB: its documented stock-information fields support a current metadata inspection, while historical identity behavior must be verified independently for the intended use. This avoids turning a narrow endpoint description into a broad product promise.

Compare operational cost only after the identity gate

Once the basket resolves correctly, compare the cost of maintaining that mapping. Can the application refresh metadata within documented limits? Are unsupported instruments distinguishable from temporarily missing data? Can the team explain and reproduce a mapping change? Record these outcomes separately from response latency.

A useful comparison sheet contains three states for every requirement: evidenced pass, observed failure, and unresolved. An unresolved mandatory identity requirement should block acceptance for the affected workflow. Optional display metadata can remain a documented limitation if the interface handles it honestly.

This method does not rank providers universally. It tells you which candidate can satisfy your application's identity contract with evidence you can maintain. A fast quote becomes useful only after the application knows what it is a quote for.

Source reviewed: TickDB Docs, Stock Information, November 12, 2026. Code examples use synthetic data and are not supplier benchmarks.

Choose a Stock API by Testing Disconnect Recovery, Not Just Streaming Speed

wang vball — Tue, 10 Nov 2026 23:26:27 +0000

A stock API can reconnect quickly while leaving an application with incomplete subscriptions or an unexplained gap in event history. Choose it by testing when data becomes usable again, not merely when the socket opens. A fresh snapshot can restore current state; only a documented replay or backfill mechanism can establish the required event continuity. The acceptance test below separates those outcomes and includes a small, locally tested recovery gate.

Start the comparison at the point where the connection breaks

A fast first message is useful, but it answers a narrow question. After a network interruption, the same client may connect successfully, receive a heartbeat, and still be missing one of the subscriptions its application needs. Alternatively, all subscriptions may return, yet trades that happened during the interruption remain absent.

These are different failures. A price display may recover once it has a valid current quote for each required instrument. A trade-derived calculation may need every event in the missing interval, with duplicates handled correctly. Do not give both applications the same definition of “recovered.”

For an API selection trial, write down two acceptance contracts before testing. The state contract specifies which instruments and fields must be restored, how freshness is judged, and whether partial availability is allowed. The history contract specifies whether missing events must be recovered, which identifier orders them, and how the application handles an interval it cannot reconstruct. An API can pass the first contract and fail the second without contradicting its documentation.

This is an evaluation method, not a ranking or a live vendor benchmark. The code below was tested with synthetic events; no provider recovery timings were measured.

Give recovery more than one finish line

Record the failure injection, the moment the client detects it, the new connection opening, subscription confirmation, reconciliation completion, and the point at which the application releases usable data. Use a monotonic clock for these local durations. Keep provider event timestamps separately; subtracting unrelated clocks can turn clock skew into an apparent latency result.

Measure at least three intervals:

Detection delay: failure injection to the client marking the session unavailable.
Transport recovery: failure injection to the replacement connection opening.
Usable-data recovery: failure injection to the application meeting its state and, where required, history contract.

If you also report recovery after the network is restored, label that start point separately. A forced ten-second outage should not be compared with a one-second outage as though they were the same test. Runs that never recover within the observation window remain failures or censored observations, not missing rows discarded from a latency average.

Figure 1. An illustrative client recovery model. Opening a connection is only one gate; this is not a vendor protocol state machine.

A successful subscription response is evidence about a subscription request, not proof that its data has arrived. Keep the desired subscription set outside the socket object, then compare it with the evidence available on the new connection. Track this per channel and instrument when the application depends on several streams. If one subscription is rejected, leave that portion unavailable rather than promoting the whole session to healthy.

A heartbeat belongs to the transport check. TickDB's Ping documentation, for example, describes a ping/pong exchange that checks connection availability. Its timestamp is not a quote timestamp, and receiving a pong does not establish that a requested stock subscription is active or that a missed trade has been recovered.

The same distinction prevents a misleading timeout rule: a quiet instrument is not automatically a broken connection. Freshness policy must respect the market session, instrument activity, and the meaning of the channel. A newly received snapshot can legitimately contain an old last-trade timestamp. If the application needs a recent trade, that instrument may remain unusable even though transport and snapshot delivery are working correctly.

Ask exactly what happens to the missing interval

Suppose the client receives event E1, disconnects while E2 and E3 occur, and reconnects before E4. A current snapshot may provide the state after E4. It does not reveal the path through E2 and E3. That distinction matters for volume accumulation, event-driven signals, and audit records, even when the displayed price looks correct.

Figure 2. Illustrative recovery semantics. Replay can repair event history only when the source supports the required interval and ordering; a snapshot alone cannot prove continuity.

For snapshot recovery, ask how the client recognizes the complete required state. Is there a completion marker, a stable expected symbol set, or an explicitly documented reconciliation procedure? A batch-size limit is not a completion signal. Nor is “no messages arrived for a moment.”

TickDB's US Full-Market Ticker documentation provides a concrete example of why these questions matter: subscribing to US_Stock sends a batched initial snapshot, then changed tickers, with at most 500 ticker messages per array. Its Best Practices page says to resend subscriptions after reconnect and that a full-market subscription receives another initial snapshot. The reviewed pages do not establish a replay cursor or an explicit snapshot-end marker. That is a documentation boundary to resolve for the intended application, not proof that those features cannot exist.

For an event-history contract, ask for the actual replay boundary: what cursor or event identifier can be resumed, how long events are retained, whether limits apply per instrument or connection, and what happens when the requested point is too old. A timestamp alone may not uniquely identify events. Do not invent deduplication using price and time unless the feed guarantees that combination is unique.

Also resolve the join between backfill and the resumed live stream. Buffering new events while fetching history is useful only when a documented ordering or watermark lets the client merge them correctly. Without that contract, a gap or a duplicate at the seam can survive a successful backfill request. Mark continuity as unverified instead of claiming that two successful requests prove it.

Test the gate independently of the network client

The following standard-library Python example demonstrates an application-level gate for a finite set of required instruments. It is deliberately not a WebSocket client or an implementation of replay. The adapter must supply subscription evidence and an explicit reconciliation decision. In production, those decisions need to come from the provider's documented semantics and the application's acceptance policy.

The generation number rejects callbacks left over from an older connection. Every reconnect starts with empty evidence, and a heartbeat cannot make the gate usable. The example uses local receipt age only; provider event-age validation belongs in the adapter before accepting a record.

from dataclasses import dataclass, field

@dataclass
class RecoveryGate:
    required: frozenset[str]
    max_age: float
    generation: int = 0
    connected: bool = False
    subscribed: bool = False
    reconciled: bool = False
    received: dict[str, float] = field(default_factory=dict)

    def begin(self):
        self.generation += 1
        self.connected = True
        self.subscribed = self.reconciled = False
        self.received.clear()
        return self.generation

    def accept(self, generation, kind, now, symbol=None):
        if generation != self.generation or not self.connected:
            return
        if kind == "disconnect":
            self.connected = self.subscribed = self.reconciled = False
            self.received.clear()
        elif kind == "subscription_ok":
            self.subscribed = True
        elif kind == "subscription_error":
            self.subscribed = self.reconciled = False
            self.received.clear()
        elif kind == "record" and self.subscribed:
            if symbol in self.required:
                self.received[symbol] = now
        elif kind == "reconciled" and self.subscribed:
            self.reconciled = True
        # Heartbeats deliberately do not advance recovery.

    def usable(self, now):
        return (
            bool(self.required)
            and self.connected and self.subscribed and self.reconciled
            and all(s in self.received and
                    0 <= now - self.received[s] <= self.max_age
                    for s in self.required)
        )

gate = RecoveryGate(frozenset({"AAA", "BBB"}), max_age=5.0)
old = gate.begin()
gate.accept(old, "disconnect", 0.0)
new = gate.begin()
gate.accept(new, "heartbeat", 1.0)
assert not gate.usable(1.0)
gate.accept(old, "subscription_ok", 1.0)  # Stale callback.
assert not gate.subscribed
gate.accept(new, "subscription_ok", 1.0)
gate.accept(new, "record", 1.0, "AAA")
gate.accept(new, "reconciled", 1.0)
assert not gate.usable(1.0)  # BBB is still missing.
gate.accept(new, "record", 2.0, "BBB")
assert gate.usable(2.0)
assert not gate.usable(7.0)  # AAA has aged out.
gate.accept(new, "subscription_error", 7.0)
assert not gate.usable(7.0)
print("Synthetic recovery-gate checks passed")

Run this as a Python 3.9-or-newer script. AAA and BBB are synthetic instrument labels, and five seconds is an illustrative receipt-age threshold, not a vendor SLA. The expected output is “Synthetic recovery-gate checks passed.”

The small gate assumes one aggregate subscription decision and serialized callbacks. A real adapter may need per-channel decisions, locking, bounded buffers, and schema checks. For an event-dependent application, do not emit “reconciled” until the missing interval and the live/backfill seam satisfy the history contract. For a display, reconciliation may be a narrower current-state decision. Keep those policies explicit rather than embedding them in the reconnect handler.

Run a failure-injection trial that can actually reject a candidate

Use the same required instruments, market session, channel mix, account permissions, client region, and outage durations for each candidate. Record the client version and subscription request so a change in the harness does not masquerade as a provider improvement. Test only connections you control, within service limits; do not generate disruptive load against a provider.

Start with four cases, because each challenges a different claim:

Clean disconnect. Close the socket, reconnect, and confirm that the desired subscriptions are restored. The pass condition is usable data under the declared contract, not a successful open callback.
Silent interruption. In a test harness or permitted local network proxy, stop delivery without a clean close. Verify that the client eventually detects the loss and stops presenting the old session as usable. Keep a fixture that delivers heartbeats but withholds records to test the separate data gate.
Partial recovery. Reject one requested subscription or withhold one required instrument in the fixture. The application must report the missing coverage and remain wholly or partially unavailable according to its predeclared policy.
Recovery race. Deliver a delayed callback from the previous connection, repeat an event, and interrupt again during reconciliation. Confirm that old-generation callbacks cannot update the new session and that any event deduplication uses a documented identity rule.

Use local fixtures to prove that the client handles these conditions; use permitted live trials to learn how a candidate behaves. A synthetic rejection is evidence about the harness and client, not evidence that a provider produces that rejection. Record those two evidence types separately.

Include a configuration failure as a separate check. For example, TickDB documents mandatory permessage-deflate negotiation for full-market subscriptions, with error 2008 when it is missing, and permission error 4005 when the key lacks access. Retrying the same invalid configuration does not demonstrate resilience. The trial should verify that the client exposes an actionable error instead of looping indefinitely. Follow the selected provider's documented retry policy and stop conditions rather than applying one universal schedule.

Make the selection from acceptance results, then compare speed

For each candidate, keep one record per injected failure: scenario, session and instruments, detection delay, transport recovery, usable-data recovery, missing subscriptions, unresolved history interval, and final outcome. Label every result as documentation-based, synthetic-test evidence, live observation, or unknown. Report the observation window and failures alongside any latency summary. With a small sample, show the individual runs instead of presenting a percentile as a stable service property.

A current-state application can accept snapshot recovery if it meets its coverage and freshness requirements. An event-dependent application needs a credible way to reconstruct the missing interval, or an explicitly accepted degraded mode that stops the affected calculation. Neither decision should be hidden inside a green connection indicator.

Reject a candidate that cannot satisfy the application's recovery contract, even if its first message arrives sooner. Among candidates that pass, compare usable-data recovery time, operating effort, and the rest of the commercial requirements. That ordering makes streaming speed useful without allowing it to conceal a broken recovery path.

Documentation basis: TickDB Best Practices, Ping, and US Full-Market Ticker, reviewed for this article. Product statements are documentation-based; the executable example uses synthetic data only.

Choose a US Stocks API That Keeps Extended Hours Data Distinct

wang vball — Mon, 09 Nov 2026 23:23:33 +0000

A US stocks API can return a valid price while leaving an extended-hours screen misleading. For a product that shows pre-market, post-market or overnight activity, choose a feed whose coverage and session semantics you can verify, then keep each observation tied to its session and timestamp. TickDB documents separate extended-session snapshot objects; Alpaca documents separate stock feeds. Those are different integration choices, and neither removes the need to test missing data and session transitions.

Suppose an overnight price panel still displays the previous regular-session trade. The number may be accurate for that earlier observation, but the panel now makes a different promise. A successful request, a familiar ticker and a recent HTTP response do not establish that the price belongs to the session the user selected.

For this kind of product, the deciding question is whether the API lets you preserve that distinction all the way from the source to the screen. A regular-hours research tool can reasonably have a narrower requirement. An extended-hours monitor needs evidence for the additional sessions, symbols and uses it promises to support.

Feed choice and session choice answer different questions

A feed identifies the data source or coverage you requested. A session identifies the trading period represented by an observation. Keep both in your evaluation notes and in your application's normalized records. A label such as “US stocks” is too broad to settle either question.

Alpaca's Real-time Stock Data documentation lists SIP, IEX, delayed SIP, BOATS and a derived overnight feed separately. It also says a subscription without access to a requested feed will fail during authentication. For an overnight use case, ask which of these sources actually serves the required observation and whether the production account can access it. Do not assume that a regular-session connection proves overnight entitlement.

TickDB takes a different shape in its documented REST snapshot: pre-market, post-market and overnight observations can appear as separate objects. Each has its own price and timestamp, and the documentation makes their presence conditional on the product and data availability. That is useful when a screen must show sessions separately, but a documented optional object is not evidence that every symbol will always have it.

These examples illustrate interface choices, not a vendor ranking. A sample payload does not prove consolidated coverage, quote completeness, historical availability or redistribution permission. Resolve those requirements for the exact feed, account and application before a production commitment.

A price should retain the session it came from

During a trial, inspect the original response before reducing it to a single price field. If a requested session is unavailable, preserve that state. Falling back to another session may make a card look populated while silently changing its meaning.

For a TickDB overnight snapshot adapter, the proposed rule is straightforward: use the documented overnight object when it exists, along with that object's timestamp. If it is absent, report unavailable rather than borrowing the top-level price. The same discipline applies to pre-market and post-market objects. Do not label the top-level field as a regular-session close without separate evidence for that meaning.

Figure 1. Proposed session-selection behavior. Optional fields remain optional; this is an adapter design, not a live response.

Preserve the original symbol, the requested source, the session label, the source timestamp and your own receipt time. The receipt time says when your application received the message. It does not, by itself, establish when the underlying market event occurred. Likewise, milliseconds or nanoseconds describe timestamp precision, not delivery speed.

Avoid using a generic “last updated” label for both clocks. An observation can be valid but old because no qualifying activity occurred, because the market is closed, or because the application has lost updates. Investigate those cases separately rather than treating every old timestamp as proof of a broken provider.

Use a calendar policy instead of a fixed UTC offset

Session classification needs a date, a market calendar and the source's documented rules. NYSE lists a normal core session of 9:30 a.m. to 4:00 p.m. Eastern Time, and its calendar includes holidays and early closes. Different venues also list different extended-hours schedules. That is enough to rule out one universal hard-coded UTC window for every US equity feed.

Use a timezone-aware calendar for the relevant venue or feed, including daylight-saving changes and exceptional days. For overnight data, also verify which trading date the provider assigns to events that cross midnight. A timestamp's local calendar date and the provider's trading date need not serve the same purpose.

The following small validator deliberately accepts a session window from the caller. It does not generate an exchange calendar or guess a session from a timestamp. Your provider-specific adapter must establish the normalized fields from the response and the configured feed; it must not invent a session label merely to make a record pass.

Turn the session requirement into an executable test

This Python example checks that an observation matches the requested symbol, feed and session, has a usable price, and falls inside a supplied half-open time window. The field names are an application schema, not a vendor API schema. The synthetic fixture verifies the local logic only; it does not query a market or measure a supplier.

from decimal import Decimal, InvalidOperation


def accept_session(record, *, symbol, feed, session,
                   start_ms, end_ms):
    # Windows are [start, end), supplied by your calendar policy.
    if not (type(start_ms) is int and type(end_ms) is int
            and start_ms < end_ms):
        raise ValueError("invalid test window")
    if record is None:
        return "unavailable"
    if not isinstance(record, dict):
        return "invalid_record"
    expected = {"symbol": symbol, "feed": feed, "session": session}
    if any(record.get(k) != v for k, v in expected.items()):
        return "scope_mismatch"
    ts = record.get("event_ms")
    if type(ts) is not int:
        return "invalid_timestamp"
    if not start_ms <= ts < end_ms:
        return "outside_session"
    try:
        price = Decimal(str(record["price"]))
    except (KeyError, InvalidOperation, ValueError):
        return "invalid_price"
    if not price.is_finite() or price <= 0:
        return "invalid_price"
    return "accepted"


# Synthetic unit-test values, not a real trading session or price.
case = dict(symbol="TEST.US", feed="fixture-feed",
            session="overnight", start_ms=1000, end_ms=2000)
row = dict(symbol="TEST.US", feed="fixture-feed",
           session="overnight", event_ms=1500, price="10.25")
assert accept_session(row, **case) == "accepted"
assert accept_session(None, **case) == "unavailable"
assert accept_session(dict(row, event_ms=999), **case) == "outside_session"
assert accept_session(dict(row, session="regular"), **case) == "scope_mismatch"

The accepted result means only that the record passed these checks. It says nothing about whether all trades were delivered or whether a quoted price is executable. The example also leaves freshness thresholds out intentionally: an appropriate threshold depends on the symbol, market state and product promise.

At ingestion, reject or quarantine records with an unknown source or session instead of filling those fields from the screen's current selection. Preserve the original payload alongside a rejected record so that a mapping error can be distinguished from missing source data. If the upstream format has finer timestamp precision than this millisecond example, retain the original precision where the application needs it.

Figure 2. Boundary tests target misleading output. Passing a sample does not establish complete market coverage.

A useful trial crosses a session boundary. Capture responses on both sides and check that the interface does not carry an earlier observation into the new session without a clear label. Then remove the requested session object from a saved fixture and confirm that the application shows unavailable. Finally, inject an event from outside the requested window and verify that the mismatch is reported rather than silently accepted.

Run these tests for the symbols and sessions the product actually needs. If a quiet symbol produces no observation, record that outcome and investigate its cause; do not turn the absence into an invented zero price or an unsupported claim that the feed lacks the symbol. A finite trial can expose failures, but it cannot prove complete future coverage.

Choose according to the product you will ship

For a regular-hours tool, a clearly bounded regular-session feed may be sufficient. For an extended-hours display, prefer an interface and entitlement package that let you identify the requested session, preserve its timestamp and represent missing observations honestly. For a cross-feed comparison, align source coverage and event types before treating price differences as errors.

A technical trial and a usage review answer different questions. Confirm the exact production access and permitted display or redistribution use with the provider; this article does not determine contractual rights. Keep unresolved requirements visible in the selection decision instead of interpreting an API success response as approval for every use.

The final acceptance condition is concrete: when the requested session changes or becomes unavailable, the product must still tell the truth about the price it displays. That is a stronger basis for choosing an extended-hours US stocks API than a demonstration that returns one plausible number.

Documentation checked November 10, 2026: TickDB REST Market Snapshot and WebSocket Ticker; Alpaca Real-time Stock Data; NYSE Holidays and Trading Hours. The code uses synthetic test fixtures, not live market results.

Disclosure: This article is prepared for TickDB's publication channels and discusses TickDB as one candidate. It is not an independent performance benchmark or investment advice.

Choose a Stock API by Testing Requirements Before Comparing Price

wang vball — Mon, 09 Nov 2026 02:08:31 +0000

A stock API can return valid JSON and still be unsuitable for your application. Choose candidates that meet your required data coverage, permitted use and operating capacity, then compare their total cost under the same workload. Alpaca’s documented IEX and SIP feed distinction shows why matching ticker symbols is not enough. A small acceptance test, with unresolved requirements kept visible, produces a more defensible shortlist than a feature count.

For an internal end-of-day research tool, prioritize the historical universe, corporate-action treatment and reproducibility. For a customer-facing price display, prioritize permission for that use, the required quote coverage and session behavior, then test delivery and recovery under load. These applications can reasonably select different providers even when their developers start with the same search: “stock API.”

The useful comparison unit is a particular feed and plan used for a particular job. A provider’s broad product page is only the beginning of that comparison. This article develops an acceptance method, not a measured ranking of providers.

Turn the application into a data contract

Start with one sentence precise enough to fail a candidate. For example: “Display last-trade prices for a defined list of US stocks during regular trading hours, with an explicit stale state, for external customers.” This is an illustrative requirement, not a statement about any provider’s license.

The words in that sentence have consequences. A last trade is different from a best bid or ask. Regular hours exclude other sessions unless you add them. External customers create a different permission question from a private prototype. An explicit stale state means the application must preserve data time and detect failures even when its own server continues answering requests.

Write down the following evidence before requesting a quote. Keep the requirements specific to the application; unnecessary requirements can eliminate a suitable, simpler service.

Requirement	Evidence to obtain	Acceptance decision
Instruments and price meaning	Symbol list, venues or feed scope, trade versus quote, session definitions	Required instruments and semantics match
Intended use	Written terms or confirmation covering audience, display, storage and redistribution where relevant	The actual use is covered
History	Date range, delisted instruments where needed, adjustment and correction policy	Research can be reproduced within the required scope
Operating capacity	Plan limits and a trial using expected subscriptions, bursts and recovery traffic	Workload fits with agreed headroom
Failure behavior	Timeout, rejection, stale-data and reconnect observations	Failures are visible and recovery is acceptable

Treat a missing answer as unresolved. It is not proof that a provider lacks a capability, but it is also not a passing result. Keep permission questions with the applicable agreement and obtain confirmation from the provider; an API response alone cannot establish permitted use.

Figure 1. Clear mandatory requirements before comparing cost and integration effort. This is a suggested evaluation process, not a provider ranking.

Compare the feed before comparing the price

Alpaca’s Market Data FAQ distinguishes an IEX feed from a SIP feed and exposes a feed choice for historical queries. That distinction matters even when both requests use the same stock symbol: a feed limited to one venue and a consolidated feed do not describe the same set of market events. A price or volume difference between them is not, by itself, evidence of an error. These statements describe the documentation reviewed on November 9, 2026, not a new market-data test.

Specify the required feed explicitly in a trial and record the account entitlement used. Otherwise, a comparison can quietly change when a subscription changes or a default selects a different feed. Compare identical sessions, event types, bar boundaries and adjustment settings wherever those controls exist. If they cannot be aligned, document the difference instead of reporting an accuracy score.

TickDB is a relevant candidate for applications evaluating US, Hong Kong and mainland China stock data: its Ticker Snapshot documentation lists examples from those markets. The same page describes a maximum of 50 symbols per snapshot request and conditional availability for fields beyond symbol, last price and timestamp. Those are useful inputs to a trial. They do not establish the feed’s suitability for every display requirement, nor do they confirm redistribution rights or measured reliability.

For a trade-price display, check the required last-price fields first. If your application also needs bid and ask, make their availability for your instruments a separate acceptance condition. A sample response containing a field is weaker evidence than a defined field contract plus a trial across the sessions you actually use.

Make unknown requirements visible in code

A weighted score can hide a fatal problem. A candidate with attractive cost and excellent documentation still cannot pass a mandatory requirement whose status is unknown. The following Python example implements that distinction before any ranking takes place.

The input is an assessment record created by your team after reviewing evidence. The names and values below are fictional; the function does not inspect contracts, query providers or measure data quality. It requires an explicit True, False or None for each mandatory criterion. Missing entries remain unresolved.

REQUIRED = ("coverage", "permitted_use", "capacity", "recovery")


def assess(checks):
    failed, unknown = [], []
    for name in REQUIRED:
        value = checks.get(name)
        if value is not True and value is not False and value is not None:
            raise ValueError(f"{name}: use True, False or None")
        if value is False:
            failed.append(name)
        elif value is None:
            unknown.append(name)
    status = "reject" if failed else "hold" if unknown else "eligible"
    return {"status": status, "failed": failed, "unknown": unknown}


candidates = {
    "Candidate A": dict.fromkeys(REQUIRED, True),
    "Candidate B": {**dict.fromkeys(REQUIRED, True),
                    "permitted_use": None},
    "Candidate C": {**dict.fromkeys(REQUIRED, True),
                    "capacity": False},
}
for name, checks in candidates.items():
    print(name, assess(checks))

A becomes eligible for comparison; B stays on hold until the permission question is resolved; C fails the current capacity requirement. A failed requirement takes precedence over an unknown one, while the returned record retains both lists. “Reject” means unsuitable under the assessed requirements and plan, not unsuitable for every customer.

Attach an evidence reference, reviewer and review date to each real assessment in your own record system. The compact code deliberately omits that storage layer. Rerun the decision when requirements or plans change; a saved Boolean should not outlive the evidence that justified it.

Run a trial that can reveal a bad fit

Use the same instrument set, time window, receiving environment and requested data meaning for each candidate. Include actively traded instruments, less active instruments and any relevant session transitions. A quiet stock’s old last-trade timestamp may simply mean that no new trade occurred. Measure transport health separately from event age so that you do not label all inactivity as an outage.

Record request start and completion times, HTTP status, requested and returned symbols, source timestamps and parse failures. For streams, also record subscription acknowledgements, disconnects and the first valid update after recovery. Preserve enough raw samples to investigate a discrepancy without retaining credentials. Use a monotonic clock for elapsed durations and a synchronized wall clock when comparing data timestamps with receive time.

Calculate request success as successful requests divided by attempted requests, and report missing requested symbols separately. A successful HTTP response can still omit an instrument. Define a freshness threshold from the application’s needs before the trial, report the eligible observation count, and separate regular hours from closed sessions. Receive time minus source time includes more than network delay and depends on timestamp semantics; do not label it end-to-end feed latency without that qualification.

Figure 2. Apply the same workload and preserve evidence before accepting a candidate. The diagram represents a proposed test, not measured results.

Test a controlled interruption as well as normal delivery. After reconnection, determine whether the service returns only a current snapshot, resumes updates or offers a documented way to recover the missing interval. A live display may tolerate an explicit stale state followed by a new snapshot. A system that must retain every event needs a stronger recovery contract. A short successful trial cannot prove a long-term availability commitment; assess the agreement and longer observation window separately.

Compare total cost among eligible candidates

Once the mandatory requirements pass, compare costs over the same period, currency and workload. Include the subscription, applicable data permissions or fees, extra usage, storage, network egress, implementation and ongoing operation. Record each item as quoted, included, estimated or unresolved. No provider prices or permission grants are assumed here.

Keep one-time migration effort separate from recurring spend, then evaluate both over a stated planning horizon. For example, an inexpensive subscription can require extra work if the application must compensate for a missing historical workflow. Conversely, a richer feed can be unnecessary expense when the application only requires a permitted delayed display. Neither conclusion follows from the headline price alone.

TickDB should pass the same assessment as every other candidate: confirm the intended usage and plan capacity, test the required instruments and fields, and record the unresolved items before comparing cost. Documentation can justify a shortlist; it cannot substitute for a workload trial or a permission decision.

The final selection record should say which requirement each candidate passed, what remains unknown, the cost assumptions and the conditions that would trigger reevaluation. If only one candidate passes, you have a conditional choice. If none pass, revise the plan, narrow the application requirement where acceptable, or keep searching. Lowering a score threshold does not resolve a failed requirement.

Source basis: Alpaca Market Data FAQ and TickDB Ticker Snapshot documentation, reviewed November 9, 2026. Product statements above are documentation-based. The assessment example uses fictional inputs; no live provider benchmark or contract review was performed for this article.

Disclosure: Prepared as technical content for the TickDB promotion workflow. This is not an independent provider benchmark.

Stock API Watchlists Can Share Requests Without Hiding Stale Prices

wang vball — Thu, 05 Nov 2026 14:23:28 +0000

Stock API Watchlists Can Share Requests Without Hiding Stale Prices

Summary: A stock watchlist can exhaust an API budget even when every user follows the same symbols. Where data permissions allow it, batching those symbols and sharing retrieval across viewers reduces duplicate upstream requests while preserving each record's timestamp. In a hypothetical case with 20 identical 120-symbol watchlists, batches of 50, and a five-second polling interval, independent polling needs 720 requests per minute; one shared collector needs 36, before retries and other traffic.

A stock API lets software request or receive stock-related data. In a watchlist, the application uses that interface to populate rows with prices and other available fields. The same data can support a portfolio overview or a research dashboard, but the API does not decide how often the screen should refresh or how the application should label an old observation.

Those decisions become visible as an app grows. If every open browser starts its own polling loop, upstream requests grow with the audience even when the requested symbols are identical. A shared collector can remove that duplication. It must also preserve data age: serving an old record quickly does not make the record current.

Count upstream requests before choosing a refresh interval

For polling, count the batches needed for one refresh cycle, then multiply by the cycles per minute. If 120 distinct symbols fit into batches of at most 50, each cycle needs three requests. A five-second interval gives 12 cycles per minute, or 36 requests per minute for one collector.

Twenty independent collectors doing the same work require 720 requests per minute. One collector serving those same viewers still needs 36 upstream requests per minute under these assumptions. The application must still deliver updates to its clients; sharing retrieval does not remove that downstream work.

The batch size has a concrete implementation example: TickDB provides a Ticker Snapshot endpoint that accepts up to 50 symbols per request. Its response includes the symbol, last traded price, and a timestamp; other market-data fields are conditional on the product, session, and availability. This makes it a useful example for a watchlist adapter, provided the selected plan and data permissions fit the application.

The calculation below is an offline planning tool. It uses synthetic identifiers, makes no API calls, and assumes all lists belong to one permitted sharing group with the same feed, fields, and refresh cadence.

from math import ceil, isfinite

def request_budget(watchlists, batch_size, interval_s):
    if type(batch_size) is not int or batch_size <= 0:
        raise ValueError("batch_size must be a positive integer")
    if not isfinite(interval_s) or interval_s <= 0:
        raise ValueError("interval_s must be positive and finite")
    lists = [set(symbols) for symbols in watchlists]
    union = set().union(*lists)
    cycles_per_minute = 60 / interval_s
    independent = sum(ceil(len(s) / batch_size) for s in lists)
    shared = ceil(len(union) / batch_size)
    return {
        "independent_rpm": independent * cycles_per_minute,
        "shared_rpm": shared * cycles_per_minute,
    }

symbols = [f"DEMO_{i:03d}" for i in range(120)]
print(request_budget([symbols] * 20, 50, 5))
# {'independent_rpm': 720.0, 'shared_rpm': 36.0}

The function deduplicates symbols within each list and across the sharing group. For different watchlists, it uses their actual union rather than assuming every viewer follows the same stocks. Separate groups must be calculated separately.

These are steady-state average HTTP request counts, not a bill, a measured benchmark, or proof that a plan has enough capacity. They omit retries, startup requests, other endpoints, and provider-specific charging units. Short-window burst limits also matter: three simultaneous requests and three evenly spaced requests have the same average but different burst behavior.

Figure 1. Calculated example, not a performance test. Twenty viewers follow the same 120 symbols, with 50 symbols per request and a five-second polling interval. Counts exclude retries and other traffic; shared delivery assumes compatible permissions.

Share collection only across compatible requests

The collector should combine subscriptions or polling demand for the same data, then distribute the results to authorized viewers. Keep the provider credential on the server. Each browser connects to the application using its own authenticated session, and the application checks what that viewer may receive.

A cache key needs enough context to prevent unlike records from colliding. Include the instrument identity and relevant feed, session, and data-mode settings. Separate entitlement groups when their access differs. A delayed feed and a real-time feed should not become interchangeable because they use the same ticker string.

Request sharing is an application design choice. It does not itself establish permission to display or redistribute a provider's data. Confirm that the intended audience and delivery model are allowed before combining viewers into one sharing group.

For a polling implementation, keep one refresh operation in flight per shared batch. If a slow response is still pending, a new screen refresh should reuse the available cache or wait for that operation rather than start an identical upstream request. When the last viewer leaves, remove unused demand after a deliberate grace period. In an application with several server instances, coordinate collection so each instance does not recreate the same upstream workload.

Figure 2. Suggested application architecture using TickDB snapshots as the source. The collector, cache, and viewer authorization belong to the application. Sharing requires compatible data permissions; the diagram does not assert redistribution rights or measured performance.

A cache hit says nothing about market freshness

Keep the provider timestamp, the time your server received the record, and the time the browser rendered it as separate values. TickDB documents its snapshot timestamp in Unix milliseconds. Preserve that value and confirm its event meaning for the selected data before using it to measure market-data latency.

A local cache lifetime tells the application when to attempt another fetch. It does not guarantee that the next response will contain a newer market observation. Polling every second can return the same last-trade price repeatedly, especially when a stock is inactive or its trading session has ended.

Display wording should reflect what the application knows. “Last checked” can describe a successful fetch. “Data as of” can show the provider timestamp. “Refresh failed” can explain why an older value remains visible. Do not overwrite the original timestamp with the current browser time and label the result live.

Choose freshness thresholds for the field and session being displayed. An old last trade during a quiet period is different from a failed connection. A watchlist can retain the last available value while showing that updates are unavailable; a feature that needs fresher input can decline to use it. Missing optional fields should remain unavailable rather than becoming zero.

Streaming changes the workload but keeps the state problem

A WebSocket stream can replace repeated snapshot requests when the application needs ongoing updates. TickDB documents a ticker channel with symbol-level subscribe and unsubscribe commands. A shared server connection can maintain the union of current demand, subject to the provider's connection and subscription limits and the application's data permissions.

Receiving events and repainting the screen are separate operations. The application can maintain its latest record for each symbol while rendering the visible watchlist at a manageable cadence. That is appropriate for a latest-value display. It is not a substitute for retaining every event when the task is trade analysis, auditing, or another event-complete workflow.

A connected socket alone does not establish that every requested symbol is subscribed or current. Track subscription outcomes and connection health separately from each record's timestamp. After a disconnect, show the loss of updates and follow the provider's recovery behavior before declaring the view current again. A new snapshot restores a latest-value view; it does not reconstruct events missed during the interruption.

Handle limits without multiplying the load

TickDB's error documentation distinguishes rate limiting, exhausted quota, connection limits, and subscription limits. For its rate-limit error, the documented action is to wait for the Retry-After duration. A permissions error or exhausted quota requires a different response; repeatedly retrying it will not create access.

Make the shared collector responsible for retries. If every waiting browser retries on its own, one failed refresh can turn into a burst of duplicate upstream requests. Use bounded retries and jitter where appropriate, reserve capacity for other work, and keep a visible degraded state while updates are unavailable. A quota budget should leave room for recovery traffic rather than allocate every request to routine refreshes.

Open source does not remove the upstream limits

Open-source stock-data clients are available. Databento, for example, publishes an open-source Python client for its market-data service. Such software can make integration easier to inspect and extend, but the client's license does not define the service's data access, request limits, or display permissions.

For a watchlist, inspect whether a client batches symbols, retries automatically, or creates one connection per instance. A wrapper can simplify a request while still duplicating the same work across viewers. The application remains responsible for its total demand and for how it presents cached values.

Before shipping, test two viewers requesting the same data at once, a refresh that takes longer than its interval, an omitted symbol, and an upstream limit response. Confirm that duplicate work stays controlled and that old values keep their original timestamps. The result should be a watchlist whose request volume and freshness labels remain understandable as more people open it.

Documentation basis: TickDB Ticker Snapshot, Real-Time Quotes and Error Codes, and the Databento Python client repository, checked November 5, 2026. The request-volume example is calculated from stated assumptions, not measured on a live service.

Stock API Charts Need Complete Downloads and Explicit Data Gaps

wang vball — Wed, 04 Nov 2026 23:21:16 +0000

Stock API Charts Need Complete Downloads and Explicit Data Gaps

Summary: A stock chart can look convincing even when its history is incomplete. A stock API supplies records under specific retrieval and aggregation rules; your application must finish the download and preserve missing observations. This article explains pagination, absent candles, and a small Python example that keeps an unknown price from becoming a false market move.

A stock API is a programmatic interface for retrieving stock-related data. For a historical chart, that often means requesting bars: records containing open, high, low, close, and volume for an interval. Those records can power chart viewers, research dashboards, and historical comparisons. They do not, by themselves, establish that every part of your requested window has been downloaded.

Consider a chart that has prices before and after a missing minute. Replacing the missing price with zero invents a collapse. Repeating the previous price creates a flat segment that was never observed. A sound implementation keeps the absence explicit while it determines whether the cause is normal market behavior, a retrieval problem, or a coverage limit.

A successful response may contain only part of the history

The first completeness check belongs in the downloader. An HTTP success means a request succeeded; a paginated endpoint may still have more records to return.

Alpaca's Historical bars documentation gives a concrete example. Its multi-symbol results are ordered by symbol and then timestamp, so the first page can contain only one symbol. The page limit applies across the response, and a short page can still have a continuation token. An application must follow the documented token rather than decide that fewer rows means the download is finished.

That behavior is specific to the endpoint. Other APIs use different retrieval controls. TickDB's Candlestick Data endpoint, for example, exposes a symbol, interval, time bounds, and a record limit. Its documentation caps the limit at 1,000 and says the Free plan cannot specify start or end times. These constraints matter when designing a history browser: access to recent candles does not automatically provide arbitrary historical navigation.

Keep retrieval logic in the provider adapter. Confirm how boundaries and ordering work before splitting a request into time windows. If that behavior is undocumented, treat it as an unresolved integration requirement; guessing how to advance a timestamp can skip records or repeatedly retrieve the same window.

Figure 1. Suggested application flow. Retrieval follows the chosen endpoint's rules; validation and gap handling happen before rendering. This is a design illustration, not a measured system result.

An absent candle does not identify its own cause

Once retrieval has finished, a missing interval still needs interpretation. Databento's Aggregate bars documentation states that an interval without a trade produces no record. Under that convention, an absent bar can be an expected result. It does not establish that the service lost data, and the rule should not be assumed for every provider.

Start with the query context. Was the instrument trading during that period? Does the selected dataset cover the session you want? Does the provider omit intervals without qualifying observations? Did the downloader finish all required requests? These questions distinguish expected absence from an unexplained gap.

An exchange calendar also belongs in this interpretation. Do not generate a continuous minute grid across nights, weekends, and holidays and label every empty slot a failure. Use the calendar and session policy appropriate to the instrument. Keep timestamp conversion separate from session selection, including daylight saving changes.

Bar boundaries need their own check. Databento documents that its daily OHLCV schema follows UTC dates. A daily bucket therefore should not automatically be treated as the exchange-session day your chart intends to show.

Until the cause is established, a useful status is simply “no bar returned.” Labels such as “market closed” or “no trades” make stronger claims and need supporting context.

Keep missing prices separate from derived display values

Suppose a synthetic series has a close of 100.00 at 14:30 UTC, no returned bar at 14:31, and a close of 101.00 at 14:32. The missing slot contains no observed close. It is neither a zero nor proof that the price stayed at 100.00.

For a close-price line, pass an explicit missing value to the chart adapter and configure the renderer to show a break. Some charting systems connect surrounding observations unless told otherwise, so inspect the rendered result as well as the input array. For candlesticks, do not manufacture an OHLC record from a missing slot.

Forward filling can serve a different purpose, such as displaying a last-known value in a dashboard. Preserve its original observation time and mark it as carried forward. Store that derived value separately from the observed series so it cannot silently become a reported trade or candle.

Figure 2. Synthetic close-price example in UTC. The middle slot has no returned observation. Its cause is unknown from these records alone; it must not become an invented zero-price candle.

A small adapter that preserves the missing slot

The following Python example runs offline with synthetic data. It accepts an already selected, increasing UTC time grid and normalized close records for one instrument. It preserves missing slots, accepts identical duplicate records, and rejects conflicting duplicates instead of silently choosing a value.

from decimal import Decimal

def align_closes(slots, rows):
    if slots != sorted(set(slots)):
        raise ValueError("Slots must be unique and increasing")
    allowed = set(slots)
    observed = {}
    for row in rows:
        time = row["time"]
        if time not in allowed:
            raise ValueError("Bar outside the selected grid")
        close = Decimal(str(row["close"]))
        if not close.is_finite() or close <= 0:
            raise ValueError("Expected a positive finite stock close")
        if time in observed and observed[time] != close:
            raise ValueError("Conflicting close for the same slot")
        observed[time] = close
    return [(time, observed.get(time)) for time in slots]

slots = ["14:30", "14:31", "14:32"]  # Synthetic UTC grid
rows = [
    {"time": "14:30", "close": "100.00"},
    {"time": "14:32", "close": "101.00"},
]
for time, close in align_closes(slots, rows):
    print(time, "MISSING" if close is None else close)

The output is 14:30 100.00, 14:31 MISSING, and 14:32 101.00 on separate lines. The function has preserved what the input says without claiming why the middle slot is absent.

This is a close-series example, not a downloader or exchange calendar. Production adapters should use full normalized timestamps rather than time-of-day strings, partition records by instrument and series settings, and validate the complete OHLCV record. A conflicting revision may be legitimate, but resolving it requires a documented revision policy. Raising an error here makes that decision visible.

Open source helps with implementation but cannot restore absent history

Open-source clients and data-processing tools can help build a stock API application. The distinction is between the software you can inspect or run and the underlying market-data service. An open-source client does not establish the upstream feed's coverage, usage rights, or historical depth.

For this charting task, inspect what the client does with pagination and missing values. A convenient wrapper may return a clean table while hiding a truncated query or a fill operation. Trace those transformations before using the result for research.

The same separation applies when using TickDB: the chart layer should retain the requested series settings and retrieval status alongside the returned candles. TickDB also documents that the final candle may still be forming. Mark that record as provisional when applicable; a changing current bar and an absent historical bar require different display behavior.

Verify the window before calling the chart complete

An acceptance check should cover more than whether the chart renders. Confirm that retrieval reached the endpoint's documented stopping condition, that the result is partitioned by the intended instrument and settings, and that unexplained gaps remain visible. Exercise an unfinished download, a missing slot, an identical duplicate, and a conflicting duplicate. Each should produce a deliberate result.

Do not turn the ratio of returned bars to clock minutes into a completeness score without establishing the expected-bar policy. A sparse instrument can legitimately have fewer bars under a trade-based aggregation rule. Conversely, a full-looking grid can conceal invented values.

The useful promise of a historical chart is that its displayed observations and limitations can be explained. A stock API supplies the records. The application must preserve the difference between a value that was observed, a value it derived, and a value it does not know.

Source basis: Alpaca Historical bars, Databento Aggregate bars, and TickDB Candlestick Data documentation, checked November 4, 2026. Code and numerical examples are synthetic.

Stock API Price Alerts Need State as Well as a Price Threshold

wang vball — Tue, 03 Nov 2026 23:53:02 +0000

Stock API Price Alerts Need State as Well as a Price Threshold

Summary: A stock API can supply prices for an alert, but a successful subscription does not define when a notification should fire. A useful alert needs an observation type, a trigger rule, remembered state, and a policy for missing data. In a synthetic five-update example, checking whether the price exceeds $100 produces three matches, while detecting an observed upward crossing produces two events. The distinction prevents repeated updates above the threshold from becoming repeated crossing alerts.

What the API contributes to a price alert

A stock API gives software access to stock-related observations, such as recent prices, trades, quotes, or historical bars. A price alert is one application of that data. The API supplies observations; the application decides which observations qualify, whether the rule has changed state, and what message to deliver.

That division matters even for a small watchlist. The expression price > 100 answers whether the current value is above a threshold. It does not say whether this is the first time the application has seen that condition, whether a notification has already been sent, or what happened during a disconnection.

For a straightforward implementation, start with one instrument and one definition: notify when two consecutive eligible observations move from at or below $100 to above $100. “Eligible” means that the observations meet your chosen price type, feed, session, freshness, and ordering requirements. This is an observed crossing in the data your application accepts; it is not a claim that every market event was captured.

TickDB's ticker documentation, for example, provides stock messages with a symbol, a latest-price field, and a timestamp. Those are useful inputs to an alerting application. Reading that schema does not establish that a ticker update represents every individual trade, nor does it supply the application's notification policy.

Figure 1. Suggested application flow. Eligibility, trigger state, and notification delivery are separate responsibilities; the diagram is not a provider architecture or a delivery guarantee.

Decide whether the user wants a condition or a crossing

Suppose five accepted observations arrive in this order: $99, $101, $102, $100, and $101. These are synthetic values, not a market replay.

Checking price > 100 matches the second, third, and fifth observations. That can be appropriate for a status indicator that stays active while the condition is true. If each match sends a message, however, a user asking for an upward-crossing alert receives an extra notification at $102 even though the previous observation was already above $100.

A crossing rule compares the current observation with the previous eligible one. It fires at the second and fifth updates. The fourth update, exactly $100, puts the rule back on the at-or-below side. Under this definition, reaching $100 is not an upward crossing; moving above it is.

There are other valid policies. A one-time target alert can deactivate permanently after its first event. A condition alert can notify immediately when enabled above the threshold. A crossing alert can use the first observation only to establish a baseline. Choose one behavior and describe it in the interface. Quietly mixing them makes it difficult to explain apparently missing or repeated messages.

Figure 2. Synthetic observations for a threshold of $100. Values above the threshold occur three times; upward crossings between accepted observations occur twice.

Choose data that can answer the rule

An alert about the latest reported trade, the best ask, and a bar close represents three different tasks. A daily-close alert can use completed daily bars under an explicit session policy. An intraday trade alert needs observations appropriate to that definition. A latest-price field with unclear semantics is not enough to claim either behavior.

Polling also limits what the application can observe. Imagine two polls both return $99, while the price briefly rises to $101 and returns between them. Comparing the two snapshots cannot reveal that excursion. A bar high may indicate that the interval contained an above-threshold value, but it does not reconstruct every crossing or its exact sequence.

Streaming can reduce that sampling gap, but its usefulness still depends on the feed and channel. A ticker stream may summarize changes; a trade stream has its own coverage and filtering rules. Neither a WebSocket connection nor the word “real-time” proves complete observation of every relevant event.

Subscription success is another separate check. Alpaca's streaming documentation distinguishes connection, authentication, and subscription, and returns the active subscription list after changes. An application should verify the requested feed and symbols rather than treating an open socket as proof that the intended observations are arriving.

A minimal observed-crossing detector

The following Python example isolates the rule from the network and notification service. It requires only the standard library. Prices are synthetic decimal strings, and the caller must provide already validated, ordered observations for one rule. The threshold is fixed at $100 for this example.

from decimal import Decimal, InvalidOperation

class UpwardCrossing:
    def __init__(self):
        self.threshold = Decimal("100")
        self.previous = None

    def reset(self):
        self.previous = None

    def observe(self, text):
        try:
            price = Decimal(str(text))
        except InvalidOperation as exc:
            raise ValueError("Expected a decimal price") from exc
        if not price.is_finite() or price <= 0:
            raise ValueError("Expected a finite positive price")
        crossed = (
            self.previous is not None
            and self.previous <= self.threshold < price
        )
        self.previous = price
        return crossed

# Synthetic observations; no API call or message delivery.
rule = UpwardCrossing()
prices = ["99", "101", "102", "100", "101"]
events = [i for i, p in enumerate(prices, 1) if rule.observe(p)]
print(events)  # [2, 5]

Repeated observations on the same side of the threshold do not produce another crossing. An initial value above $100 produces no event because the rule has no earlier baseline. Invalid numeric input raises an error without replacing the previous value. The surrounding application must decide whether that error also means continuity is uncertain and requires a reset.

Use separate state for each instrument and rule configuration. Do not feed several symbols through one instance or change the price definition while retaining the old baseline. This small detector does not validate timestamps, identify duplicate events, process corrections, persist state, or send notifications.

It also does not suppress repeated genuine oscillations around $100. A cooldown limits notification frequency, while hysteresis requires a lower rearming level before another trigger. Both change the user-visible policy. Add them only when their behavior matches the alert the user requested.

A reconnect cannot fill in an unseen interval

Suppose the last accepted value before a connection loss was $99 and the first value after recovery is $101. The endpoint observations are on different sides, but the application did not observe the intervening sequence. Its UI should not imply that it watched a specific crossing happen continuously.

One conservative policy is to mark the rule unavailable during the interruption, reconnect and restore the subscription, then use the first eligible observation as a new baseline. In the example, the caller invokes reset() when continuity is lost. The next call to observe() establishes state without firing. This deliberately sacrifices possible alerts during the gap in exchange for a clear live-observation policy.

TickDB's WebSocket guidance explicitly calls for resubscribing after reconnect and notes that full-market subscriptions receive another initial snapshot. That describes how to resume receiving data. A snapshot establishes current state; it does not reconstruct the sequence of missed observations. Where suitable history is available, a separate recovery process can evaluate it and label resulting notifications as retrospective.

The same policy question arises at startup, a session change, or a restart that loses in-memory state. Persisting the previous price alone is insufficient if you cannot establish continuity with the next observation. Record the interruption and the rule's status so that silence is not mistaken for evidence that the threshold was never crossed.

Detecting an event and delivering it are separate outcomes

An alert event can be detected correctly while the notification service is unavailable. Conversely, retrying a delivery after an uncertain response can produce duplicate messages even if the crossing detector ran only once.

For a durable implementation, persist the updated rule state and its alert event together, then let a delivery worker process that event with a stable identifier. Track pending, delivered, and failed attempts separately. Where the destination supports idempotency, reuse the event identifier on retries. If it does not, an ambiguous delivery result can still leave a duplicate risk; the price rule cannot solve that on its own.

This is an application design recommendation, not a guarantee supplied by a stock API or by the sample code. A market-data subscription also does not place a trade. Order submission and execution belong to a separate workflow with its own account permissions and outcomes.

Verify the behavior the user will actually see

Before connecting live data, run a short synthetic sequence through the rule and inspect the events. Include an initial value above the threshold, several values staying above it, a return to exactly the threshold, a new upward crossing, and a reset during a gap. Then exercise the surrounding application with stale inputs, out-of-order observations, a failed subscription, and notification retries.

An open source client can help receive and parse data, but it does not choose these policies for the application. The useful promise is precise: which observations qualify, what transition creates an event, when the rule is unavailable, and how delivery status is reported. That gives a stock API alert a meaning the user can understand and a behavior the developer can verify.

Sources consulted on November 3, 2026: TickDB Docs, Real-Time Quotes and WebSocket Best Practices; Alpaca, WebSocket Stream. The code and price sequences are offline demonstrations. No live feed completeness, latency, notification delivery, or trading performance is claimed.

Why Stock API Prices Differ and Which Price Your App Should Use

wang vball — Mon, 02 Nov 2026 23:46:02 +0000

Why Stock API Prices Differ and Which Price Your App Should Use

Summary: Why does a stock API show a different price from a chart or brokerage screen? The values may describe different trades, quotes, sessions, feeds, or adjustment rules. Choose a price definition for each feature before comparing numbers: a watchlist can display the latest reported trade, a spread display needs bid and ask, and a historical chart needs a consistent bar and adjustment policy. A worked quote example shows why several valid prices can coexist for one stock.

One stock can have several meaningful prices

A stock API lets an application retrieve or subscribe to stock-related data. It does not make “the stock price” a single, universal field. The value you receive might represent a transaction, an available quote, an aggregate, or a historical series transformed for comparison over time.

Imagine a synthetic stock whose latest reported trade is $100.00. A subsequent quote shows a $99.98 bid and a $100.06 ask. Its previous regular-session close was $99.50. A watchlist, a spread display, and a daily-change calculation can legitimately use different numbers from this set.

The first question is what each number describes. A difference alone does not establish that a provider is wrong. Equally, different definitions should not become a blanket excuse for bad data: once the instrument, observation, and conventions are aligned, unexplained discrepancies deserve investigation.

Trade prices and quoted prices answer different questions

The last trade reports a completed transaction included by the feed. A bid is a quoted buying price; an ask is a quoted selling price. The best bid and ask refer to the coverage of the selected feed, which may be narrower than the overall market.

For the synthetic quote above, the spread is $0.08 and the midpoint is $100.02. The midpoint is an arithmetic reference derived from the two quote sides. There need not have been a trade at that price. The earlier $100.00 trade can remain the latest trade while the quote changes around it.

This distinction helps define an alert. “Notify me when a reported trade exceeds $100” and “notify me when the ask exceeds $100” describe different conditions. Choose the observation type explicitly, then decide how the application handles repeated updates and reconnects. A price alert also remains separate from an order: a displayed quote does not guarantee an execution at that price or for the desired quantity.

Alpaca's Latest Quotes reference makes the distinction concrete by describing best bid and ask prices and exposing a feed parameter. Its documented feed choices include IEX, SIP, and delayed SIP. The endpoint name alone therefore does not establish the venue coverage or freshness of a particular response.

Figure 1. Synthetic USD values for one stock. The midpoint and spread are calculated from the bid and ask; the last trade is a separate observation. No live market data is shown.

A close needs an interval and a session

In an OHLCV bar, the close is the closing value of a specified interval under the provider's aggregation rules. OHLCV stands for open, high, low, close, and volume. A one-minute close and a daily close summarize different intervals; neither is automatically the latest price available now.

A daily bar also needs a session definition. Ask whether it includes extended hours and whether the application needs an exchange's official closing value or the close of a vendor-generated bar. Those terms should not be treated as interchangeable without checking the documentation. Databento's schema guide notes that OHLCV results can vary with interval boundaries and the handling of trade breaks, halts, and periods with no trades.

For a daily-change feature, preserve the reference as well as the current value. In the synthetic example, comparing the $100.00 last trade with the $99.50 previous regular-session close produces approximately +0.50%. Substituting the $100.02 midpoint produces approximately +0.52%. Both calculations are arithmetically correct, but they describe different measures. Label the chosen measure and keep it consistent across the application.

TickDB's ticker documentation is an example of why field descriptions matter here. It defines prev_close as the previous close or reference price for the statistics window, when available. It also says that stock fields ending in 24h usually refer to the trading day or session rather than a universal rolling 24-hour window. An application should establish that window before labeling a value “today's change.”

Adjusted history serves a different purpose

Historical charts often need to account for corporate actions. Suppose a stock undergoes a two-for-one split. Ignoring other price movement, a pre-split $100 share becomes two $50 shares. A raw price series can show a large step even though the split itself did not halve the holder's total position value.

A split-adjusted series can express earlier prices on a comparable share basis. Dividend adjustments address a different effect and should not be assumed to follow the same rules. Alpaca's Historical Bars reference, for example, exposes separate raw, split, and dividend settings.

Choose the transformation to fit the feature. A chart intended to show comparable prices across a split benefits from a stated adjustment policy. A question about what price actually printed at a historical moment calls for the corresponding raw observation. Do not join adjusted historical bars to an unadjusted live series without checking that their price bases align at the join.

Give every application feature a price definition

A small amount of explicit metadata prevents a large amount of ambiguity. Keep the instrument identity and currency, the observation type, the source feed, the relevant time, the session or interval, and the adjustment policy alongside the value. These can come from documented request settings as well as response fields; they should not be guessed from the number itself.

Feature	Price definition to choose	Label or context to preserve
Watchlist	Latest reported trade or another explicitly defined latest price	Observation type, source, and time
Spread display	Bid and ask from one coherent quote	Feed coverage, quote time, and sizes when available
Daily change	Chosen current value versus a defined previous close	Both price definitions and the reference session
Historical chart	Bars with a fixed interval and adjustment policy	Session coverage and adjustment basis

With TickDB or another provider, preserve useful source metadata during normalization. TickDB documents an extended-session field for US stocks with values such as pre_market, post_market, and overnight. That context can explain why a displayed update belongs to a different session from the chart beside it. If metadata is absent, record the uncertainty or resolve it from documented context instead of inventing a value.

Figure 2. Suggested application design. Define the observation and its context before reducing a stock API response to a displayed number.

A small quote calculation with an explicit boundary

This Python example calculates the midpoint and spread of a synthetic quote. It uses only the standard library and an application-defined schema. It checks numeric inputs and refuses a crossed quote, where the bid exceeds the ask, because this simple display example does not attempt to interpret that condition.

from decimal import Decimal, InvalidOperation

def quote_metrics(bid_text, ask_text):
    try:
        bid = Decimal(str(bid_text))
        ask = Decimal(str(ask_text))
    except InvalidOperation as exc:
        raise ValueError("Expected decimal prices") from exc
    if not all(p.is_finite() and p > 0 for p in (bid, ask)):
        raise ValueError("Expected finite positive prices")
    if bid > ask:
        raise ValueError("Crossed quote requires review")
    return {"midpoint": (bid + ask) / 2, "spread": ask - bid}

# Synthetic USD quote; not a response from a live service.
metrics = quote_metrics("99.98", "100.06")
print(f"Midpoint: {metrics['midpoint']:.2f} USD")
print(f"Spread: {metrics['spread']:.2f} USD")

The output is Midpoint: 100.02 USD and Spread: 0.08 USD. The code deliberately does not call the midpoint a last trade or an executable price. Before applying it to live data, ensure both sides refer to the same instrument, currency, feed, and coherent quote state. On a stream that sends partial updates, maintaining that state requires the provider's update rules.

This calculation cannot certify quote freshness, available liquidity, or market-wide coverage. A zero spread is possible for a locked quote and is not rejected here; accepting that arithmetic result still says nothing about whether a trade can be executed. Input validation protects the calculation from obvious misuse, while market interpretation requires more context.

When a difference becomes worth investigating

To compare an API value with another screen, capture both observations and their metadata before refreshing either one. Match the instrument and currency, then the price type, feed scope, time, session, and adjustment basis. For historical bars, match the exact interval and aggregation conventions as well.

If those conditions align and a discrepancy remains, retain the original payloads and request parameters. Check delayed access, cache behavior, missing updates, corrections, and normalization errors. Two requests made at different moments are not a controlled comparison of the same event.

Changing to an open source client does not resolve these definitions automatically. A client can make requests easier to write, but it still consumes a particular upstream feed and must interpret that feed's records. The useful result for the user is a price with an understandable meaning: a latest trade, a bid and ask, a defined close, or an adjusted historical value, accompanied by enough context to use it correctly.

Sources consulted on November 2, 2026: Alpaca, Latest Quotes and Historical Bars; Databento, What's a Schema; TickDB Docs, Real-Time Quotes. All numerical examples and diagrams are synthetic or conceptual, not live measurements or supplier performance comparisons.

A Stock API Provides Market Data for Apps Within Feed and Usage Limits

wang vball — Mon, 02 Nov 2026 00:02:52 +0000

A Stock API Provides Market Data for Apps Within Feed and Usage Limits

Summary: A stock API gives an application programmatic access to prices and related financial data, but what can you build with it? Charts, watchlists, research tools, and alerts are common uses; their reliability depends on the feed, timestamps, data definitions, and permitted use. A latest trade, a bid–ask quote, and a daily price bar describe different things, while an open source client library grants no automatic rights to redistribute the underlying data.

What a stock API actually provides

A stock API is an interface through which software requests or receives stock-related data. An application can use it to retrieve recent prices, download historical observations, or subscribe to updates. Some services also expose company fundamentals, corporate actions, or news through separate endpoints.

The interface makes data accessible to code. The feed behind it determines which events are represented, how quickly they arrive, and how much history is available. Two services can both return a price for the same ticker while describing different observations.

An endpoint is a particular operation offered by the service, such as retrieving historical bars. Many APIs deliver a structured response, often JSON, that a program can parse into fields. An SDK is a client library that wraps those operations in convenient functions. Installing an SDK does not change the coverage or permissions of the underlying service.

It also helps to separate market data from trading. Reading a price does not submit an order. A trading application may use a market data API alongside a broker API for account information, order placement, and execution reports. Even when one provider offers both, these are separate capabilities.

Figure 1. A conceptual market data path. Feed coverage and normalization affect what reaches the application; a trade and a quote describe different events.

The data type determines the feature you can build

A trade records a completed transaction. A quote describes a bid and an ask within the coverage of the feed. A price bar summarizes observations over an interval, typically as open, high, low, close, and volume, or OHLCV. These records serve different purposes.

A daily bar is useful for a long-term chart, but it cannot reveal the sequence of price changes inside that day. A last-trade price can support a watchlist, but it is not a promise that a new order will execute at that price. That distinction matters as soon as a display becomes an input to an alert or trading decision.

Application	Useful data	Important boundary
Watchlist	Latest prices and timestamps	Show when the observation was recorded and whether it is delayed.
Historical chart	OHLCV bars	Keep interval, session, and adjustment settings consistent.
Price alert	A defined trade or quote stream	Handle disconnects and decide which observation triggers the alert.
Portfolio view	Prices plus holdings	Holdings and cash flows come from a separate source unless explicitly provided.
Research or backtesting	Historical observations and reference data	Check missing periods, corporate actions, and which securities existed at the time.

For example, TickDB documents a ticker stream with stock symbols, latest prices, and timestamps, including examples for US stocks, Hong Kong stocks, and A-shares. This illustrates the input a watchlist can consume. The application still has to interpret the fields, maintain its own display state, and explain the age of the observation to the reader.

REST and WebSocket describe delivery methods

With a REST-style HTTP API, the client makes a request and receives a response. This fits an on-demand lookup or a historical download. Repeating the request creates polling: the application checks again at an interval it chooses.

A WebSocket connection lets the server send updates over a persistent connection. This can suit a watchlist or alert service that needs frequent changes without repeatedly asking for the same symbols. The client must still manage subscriptions, detect a broken connection, and recover according to the provider's protocol. Reconnecting does not by itself prove that missed events have been recovered.

Neither method establishes the quality of the feed. A WebSocket can carry delayed data, and an HTTP response can contain a recent observation. Similarly, transport latency and market coverage are separate questions. Alpaca's Market Data documentation, for example, distinguishes real-time IEX coverage on its Basic equities plan from broader exchange coverage on another plan. “Real-time” alone does not identify the set of venues represented.

A small example that keeps the timestamp visible

A watchlist should retain the observation time alongside the price. Otherwise, a successful request can make an old observation look current simply because the screen has just refreshed.

The following Python example runs offline using synthetic data and an application-defined schema. It requires only the standard library. It calculates observation age and applies an illustrative 60-second display threshold; it does not measure network latency or decide whether the market should be trading.

from datetime import datetime, timezone
from decimal import Decimal

def format_observation(row, now, max_age_seconds=60):
    observed = datetime.fromisoformat(
        row["observed_at"].replace("Z", "+00:00")
    )
    if observed.utcoffset() is None or now.utcoffset() is None:
        raise ValueError("Timezone-aware timestamps required")
    price = Decimal(str(row["last_price"]))
    if not price.is_finite() or price <= 0:
        raise ValueError("Expected a finite positive stock price")
    age = (now - observed).total_seconds()
    if age < 0:
        state = "check clock or timestamp semantics"
    elif age > max_age_seconds:
        state = "older than display threshold"
    else:
        state = "within display threshold"
    return f"{row['symbol']} {price} | age={age:.0f}s | {state}"

# Synthetic observation and clock; not a live API response.
sample = {
    "symbol": "EXAMPLE.US",
    "last_price": "100.25",
    "observed_at": "2026-10-28T14:30:00Z",
}
now = datetime(2026, 10, 28, 14, 31, 15, tzinfo=timezone.utc)
print(format_observation(sample, now))

The output is EXAMPLE.US 100.25 | age=75s | older than display threshold. The displayed number is still available, but the application no longer presents its recency ambiguously.

For a real integration, map the provider's fields into this small internal schema only after checking their meanings. TickDB's ticker documentation specifies Unix milliseconds for its timestamp field and describes latest prices as strings. Converting milliseconds as if they were seconds would invalidate the age calculation. Its documentation also notes that a 24h field suffix does not imply a rolling 24-hour window in every market; stock statistics usually refer to a trading day or session.

The threshold remains an application policy. An old last trade can be normal after a session ends or when an instrument has not traded recently. Use a market calendar and the feed's timestamp definition before turning an age label into a service-health warning. This example also leaves ingestion validation, symbol mapping, persistence, and recovery to the surrounding application.

Is there an open source stock API available

Yes, open source software exists for accessing stock data. The useful distinction is whether you mean an open source client, a server you can host, or a dataset with permissions that fit your project.

For example, yfinance is an open source Python library for accessing Yahoo Finance data. Its repository states that it is not affiliated with Yahoo, describes its research and educational purpose, and directs users to Yahoo's terms for rights to downloaded data. The repository also notes that the Yahoo Finance API is intended for personal use. The software license and the terms governing the data are separate.

Hosting your own API around downloaded data gives you control over your application interface. It does not create new data rights, improve the original feed's coverage, or guarantee that its upstream service will remain available. A free hosted API is a different option again: it may offer access subject to quotas and conditions without publishing its server implementation.

Figure 2. Open source software, access to a data service, and permission to use the data are separate considerations.

Limitations that matter after the first successful request

Coverage and freshness need separate checks. Confirm which markets, venues, instruments, and sessions the feed represents. A response labeled “latest” may contain the most recent available observation rather than an observation from the present moment. Extended-hours support also needs an explicit check; a regular-session chart should not silently mix in a different session.

Historical data has definitions and revisions. A split changes the relationship between share count and price. Dividend adjustments serve another purpose. Alpaca's historical bars reference exposes separate adjustment options, which illustrates why a chart should record its settings instead of relying on an unnoticed default. For a backtest, also check delisted instruments and information availability dates; today's list of surviving companies is not automatically an appropriate historical universe.

Capacity depends on the workload. Suppose a dashboard polls 120 symbols individually every 10 seconds. That is 720 requests per minute before retries. If an endpoint supports all 120 symbols in one batch, the same schedule requires six requests per minute, although the provider may meter symbols or data volume separately. Streaming reduces repeated polling but introduces connection and subscription limits of its own.

Access and public use are different requirements. An API key proves that a service accepts a credential for a request. It does not, on its own, establish permission for public display, redistribution, or every commercial use. Check the relevant data agreement for the intended application before building a public product around a personal-use prototype.

Start with a feature narrow enough to verify: one chart, a small watchlist, or one alert rule. Record its required data type, acceptable observation age, session coverage, and intended use. Then check both a normal response and an empty, delayed, or interrupted one. A stock API is useful when those conditions match the application—not merely when a request returns a price.

Sources consulted on November 1, 2026: Bavest, Stock API – What You Need to Know; Databento, Stock Market API and schema documentation; Alpaca, About Market Data API and Historical Bars; TickDB Docs, Real-Time Quotes; yfinance repository README. Examples and diagrams are explanatory, not live market measurements.