Budapest Stock Exchange Index (BUX) Price Change API for real-time monitoring and alerting setup

You need to monitor the Budapest Stock Exchange Index (BUX) in real time and fire alerts the moment its price changes beyond your thresholds. In this guide, you’ll wire up Indices-API’s latest and fluctuation endpoints to (1) fetch the current BUX level, (2) compute live deltas, and (3) schedule daily change alerts without fabricating your own data pipeline.

What we’ll build: a BUX price-change monitor and alert loop

We’ll combine two endpoints that cover the end-to-end workflow:

• Latest: poll current BUX rate during the session for real-time alerting.
• Fluctuation: check the day-over-day percentage change for alert summaries or pre-market checks.

You’ll copy one curl request and one JavaScript snippet that read the fields you actually use (base, date, timestamp, rates), interpret BUX vs USDBUX correctly, handle trading days and weekends, and cache responsibly. If you don’t yet have an API key, start with the free trial of the Pro plan ($49.99/mo, 7-day trial) and get your key here: Register.

Confirm the symbol and understand how BUX is quoted

The symbol used below is BUX (Budapest Stock Exchange Index). Always confirm the exact code on the symbols page before shipping to production: Indices-API Supported Symbols.

Indices-API responses are denominated with base = USD unless you request otherwise. In practice you’ll encounter two keys that are reciprocals of each other:

• rates.BUX — USD per 1 BUX index unit
• rates.USDBUX — BUX index units per 1 USD

Both exist to make conversions trivial depending on your use case. If you need the current index “level,” you’ll typically convert from USD to BUX via rates.USDBUX (because it’s “how many BUX per USD”). Conversely, to express an index unit in USD, use rates.BUX. Keep them consistent throughout your code, and don’t mix directions in the same computation.

Endpoint choices for price-change alerting

We’ll use two endpoints. For fuller coverage and optional extensions (OHLC, time series, intraday candles), see the Indices-API Documentation.

Fetch the current BUX quote (for real-time alerts)

Use the Latest endpoint to poll for the current session’s BUX values. The base is USD; both BUX and USDBUX appear in the rates object so you can pick the direction that fits your logic.

curl: copy/paste to verify your key and the symbol

curl -s "https://indices-api.com/api/latest?access_key=YOUR_API_KEY"

Official response example (do not change values):

{"data":{"success":true,"timestamp":1794616860,"date":"2026-11-14","base":"USD","rates":{"BUX":0.0022644946128676,"USD":1,"USDBUX":441.5996374280038}}}

Interpretation of the response

• success: true indicates the request succeeded.
• timestamp: 1794616860 is a Unix epoch (seconds). Treat it as UTC for caching and freshness checks.
• date: "2026-11-14" is the API’s reference date. On weekends or holidays this can remain the last trading day.
• base: "USD" means the rates are expressed relative to USD.
• rates.BUX: 0.0022644946128676 USD per 1 BUX index unit.
• rates.USDBUX: 441.5996374280038 BUX per 1 USD (the reciprocal of rates.BUX).
• rates.USD: 1 is the identity rate for the base currency.

For an index “level”-style number, most dashboards will use rates.USDBUX, because it’s a large, human-readable figure in BUX units. For monetary conversions (estimating USD exposure per index unit), use rates.BUX.

JavaScript example: real-time threshold alert

The snippet below polls /api/latest, extracts rates.USDBUX as the current index level proxy, smooths noisy updates via a short memory cache, and fires if the absolute or percentage change exceeds your thresholds. It also respects non-trading days by checking the date and using your last known close if appropriate.

/**
 * Minimal BUX real-time alert loop using Indices-API Latest endpoint.
 * Assumptions:
 * - base = USD
 * - Use rates.USDBUX (BUX units per USD) as the "level-like" value
 * - Fallback to prior cached value on non-trading days
 */
const ENDPOINT = "https://indices-api.com/api/latest?access_key=YOUR_API_KEY";

let lastLevel = null;
let lastTimestamp = null;

// Thresholds (tune to your needs)
const absMoveThreshold = 5;      // e.g., trigger if level moves by 5 BUX units
const pctMoveThreshold = 0.5;    // e.g., trigger if |change_pct| >= 0.5%

async function fetchLatestBUX() {
  const res = await fetch(ENDPOINT, { method: "GET" });
  if (!res.ok) throw new Error("HTTP error " + res.status);
  const json = await res.json();

  // Expected shape follows the official sample
  const { success, timestamp, date, base } = json.data || {};
  const rates = (json.data && json.data.rates) || {};
  if (!success) throw new Error("API returned success=false");
  if (base !== "USD") throw new Error("Unexpected base currency: " + base);

  // Prefer the "level-like" field
  const level = rates.USDBUX; // BUX index units per 1 USD
  const usdPerBUX = rates.BUX; // USD per 1 BUX index unit (reciprocal)

  if (typeof level !== "number" || typeof usdPerBUX !== "number") {
    throw new Error("Missing BUX or USDBUX in rates");
  }

  return { level, usdPerBUX, timestamp, date };
}

function maybeAlert(prevLevel, newLevel) {
  const absMove = newLevel - prevLevel;
  const pctMove = (absMove / prevLevel) * 100;

  const absHit = Math.abs(absMove) >= absMoveThreshold;
  const pctHit = Math.abs(pctMove) >= pctMoveThreshold;

  if (absHit || pctHit) {
    // Replace with your notifier (email, Slack, webhook, etc.)
    console.log("[ALERT] BUX move:", {
      prev: prevLevel,
      curr: newLevel,
      abs: absMove,
      pct: pctMove.toFixed(3) + "%"
    });
  }
}

async function runPoll() {
  try {
    const { level, timestamp, date } = await fetchLatestBUX();

    // Basic staleness check: timestamps are UTC seconds
    if (lastTimestamp && timestamp <= lastTimestamp) {
      // No fresher data; skip alerting
      return;
    }

    if (lastLevel !== null) {
      maybeAlert(lastLevel, level);
    } else {
      console.log("Initialized BUX level:", level, "at", date);
    }

    lastLevel = level;
    lastTimestamp = timestamp;
  } catch (err) {
    console.error("Polling error:", err.message);
  }
}

// Poll cadence: choose based on plan update frequency
// Typical values: 60s-5m; avoid hammering on weekends/holidays.
setInterval(runPoll, 60_000);
runPoll();

Notes:

• The API’s update frequency depends on your plan. Don’t poll more frequently than updates arrive; add a minimum interval in your scheduler and back off on weekends/holidays.
• Use timestamp to avoid duplicate processing; only alert when the value is fresher.
• If you prefer to compute alerts in USD terms, swap in rates.BUX.

Daily BUX percentage-change alerts with the Fluctuation endpoint

For end-of-day or pre-market summaries, the Fluctuation endpoint reports change and change_pct over a date range. You can use it to implement “BUX moved more than X% since yesterday’s close.” Practical constraints to remember:

• You cannot set end_date to “today.” Use yesterday’s or a prior trading day.
• On weekends and Hungarian market holidays, the last available business date applies.

High-level usage: query /api/fluctuation with start_date and end_date in YYYY-MM-DD, read rates.BUX.change and rates.BUX.change_pct, and compare them to your thresholds. For details on supported query parameters, see the Documentation.

Implementation tips without fabricating numbers:

• Persist the last successful fluctuation result with its end_date. Do not recompute intraday with this endpoint.
• If you need intraday percent change, compute it off two Latest snapshots: (level_now - level_open_estimate) / level_open_estimate. Get open via OHLC if you add that endpoint; otherwise choose a consistent baseline like the first poll after the market opens.

How to think about units, base currency, and conversions

Because base = USD, Indices-API expresses rates in two natural directions:

• rates.BUX (USD per 1 BUX) — multiply a BUX quantity by this to get a USD value.
• rates.USDBUX (BUX per 1 USD) — multiply a USD amount by this to get BUX units.

These two are reciprocals if both are present. Pick one convention for your stack and stick with it to avoid double-inversion bugs. When you compute percentage changes, the direction cancels out, but mixing directions across samples can result in sign or magnitude errors.

Trading days, update cadence, and caching

Handling market calendars up front saves you incident time later. For BUX (Budapest), you’ll see these patterns:

• Weekends: Latest will keep returning the most recent date and timestamp from the last trading day. Do not attempt to treat weekends as missing data; they intentionally repeat the last close or last tick depending on plan coverage.
• Holidays: Behaves like weekends. Your alerts should be dormant unless you compare against an older start_date in fluctuation queries.
• Update frequency: The latest endpoint updates based on your subscription (e.g., every 60 minutes or every 10 minutes depending on plan). Polling faster doesn’t produce fresher data; add a guard so you don’t process the same timestamp twice.
• Caching: Respect HTTP cache headers if present at your edge, and also implement an in-app cache keyed by symbol and timestamp to de-duplicate events.

Backfilling context for charts and baselines

If you also need a comparative baseline (e.g., last week’s average move) to reduce noise in alerts, query the Time-Series endpoint for a date range and compute your heuristics offline. Remember: end_date cannot be “today,” so choose a completed trading day as your upper bound. For required parameters and range limits, refer to the Documentation.

Productionizing alerts: reliability checklist

• Symbol control: Lock the BUX symbol in configuration and validate at startup against the Symbols endpoint/page.
• Data direction: Choose either rates.USDBUX or rates.BUX, not both, for all in-app comparisons.
• Timestamps: Treat timestamp as seconds since epoch (UTC). Do not compute latency or staleness from local clock drift; compare successive timestamps from the API itself.
• Weekends/holidays: Silence intra-day alerts and only run the fluctuation job against the last complete end_date.
• Rate stability: Use small exponential smoothing or a rolling window to avoid flapping alerts on micro-changes when polling near the update frequency boundary.
• Error handling: Fail closed (skip alerts) on partial JSON or when success is false. Log the raw body for diagnostics.

Compliance notes and additional references

• Always retrieve symbols and metadata from the official listing before deployment: Indices-API Supported Symbols.
• Operational posture and MCP integration details are available at: MCP.
• For market hours and holidays, consult the Budapest Stock Exchange calendar: Budapest Stock Exchange.

Common pitfalls when calculating “price change” for BUX

• Inverting twice: If you compute deltas in USD per BUX (rates.BUX) on one day and BUX per USD (rates.USDBUX) on another, you’ll get nonsensical changes. Normalize first.
• Comparing partial days: Don’t compare an intraday tick to a completed prior-day close via the fluctuation endpoint. Either use intraday-to-intraday with Latest or EOD-to-EOD with Fluctuation.
• Using end_date=today: The fluctuation endpoint requires a completed end_date. Use yesterday or the previous trading day.
• Over-polling: Hitting Latest every second won’t yield more frequent updates. Cap your polling to plan frequency and skip processing if timestamp didn’t advance.

FAQ

Q: Which field should I treat as the “BUX level”?
A: Use rates.USDBUX (BUX per USD) for a level-like number. It’s the reciprocal of rates.BUX (USD per BUX). Stick with one convention throughout your pipeline.

Q: Can I get the percentage change directly?
A: Yes, via the Fluctuation endpoint’s change_pct for BUX over a date range. Remember that end_date cannot be today; use the last completed trading day.

Q: What timezone are the timestamps in?
A: timestamp is Unix epoch seconds in UTC. Use it to detect freshness and to avoid duplicate alerting when data hasn’t advanced.

Q: How often does Latest update?
A: It depends on your subscription plan. Poll no faster than the documented update frequency and deduplicate by timestamp to prevent alert flapping.

Q: What happens on weekends or BSE holidays?
A: Latest continues to reflect the last available trading snapshot (date and timestamp). Your real-time monitor should mute or pause alerts until the market reopens, while your daily fluctuation job should run against the last completed end_date.

Get your API key and ship your BUX alerts

Spin up your BUX monitor in minutes: request an API key (Pro $49.99/mo with a 7-day trial), plug it into the curl and JavaScript above, and start alerting on real movements instead of polling spreadsheets. Sign up here: Register. For full parameter details and additional endpoints (OHLC, time series, intraday), read the Documentation.