Turkmenistani Manat (TMT) Price Change - Daily API response format and example

You need to programmatically measure the daily price change of the Turkmenistani Manat (TMT) and surface it in a dashboard, alert, or report. By the end of this walkthrough, you will be able to fetch the latest TMT price from the API, understand the daily change fields the API exposes, and wire it into a production workflow with correct handling of time, caching, and non-trading days.

What we are building: a daily TMT change readout you can ship

The concrete goal is a small, reliable component that answers “What’s the TMT price now, and how did it change versus the prior day?” You can drop it into a UI card, trigger a Slack alert if the day-over-day change exceeds your threshold, or persist the values into your data store for later analytics.

Illustration: Turkmenistani Manat (TMT) Price Change - Daily API response format and example

We will cover two endpoints, enough to ship this workflow:

Latest: get the current price fields for TMT (base is USD).
Fluctuation (daily): get machine-readable day-over-day change fields (start_rate, end_rate, change, change_pct) for TMT without manual backfills.

For everything else (historical ranges, intraday candles, OHLC), see the Indices-API Documentation.

Confirm the TMT symbol and base currency semantics

We will query the symbol TMT. If you maintain a symbol map or must validate coverage programmatically, confirm it on the Indices-API Supported Symbols page.

All prices returned by Indices-API default to a USD base. For currencies, this means:

rates.TMT is units of TMT per 1 USD.
rates.USDTMT is the inverse (USD per 1 TMT), which is often convenient for quoting a single TMT in USD terms.
rates.USD is 1 by definition when base is USD.

The request you will actually send (curl)

Below is a complete, copy-pasteable request for the latest endpoint. Replace YOUR_API_KEY with your key. If you don’t have one yet, you can start a 7-day trial on the Register page.

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

Real API response: fields you will use for TMT

This is an actual response payload for TMT from the latest endpoint. Use it to model your parser and tests.

{"data":{"success":true,"timestamp":1792820460,"date":"2026-10-24","base":"USD","rates":{"TMT":3.51571,"USD":1,"USDTMT":0.2844375673761488}}}

Field notes you will use immediately:

data.success: Boolean flag to guard downstream processing.
data.timestamp: Unix time (seconds). Treat as UTC.
data.date: Calendar day (YYYY-MM-DD) aligned to the pricing snapshot.
data.base: The base currency for all rates; for these endpoints it is USD.
data.rates.TMT: TMT per 1 USD. For the payload above, 1 USD = 3.51571 TMT.
data.rates.USDTMT: USD per 1 TMT. For the payload above, 1 TMT ≈ 0.2844375674 USD.

JavaScript example: fetch the latest TMT quote and read daily-change fields

This sample fetches the latest TMT price first. In a production integration, you will either compute the daily change yourself (latest vs. prior close) using time-series data, or call the fluctuation endpoint for machine-ready change fields. The code below shows both calls so you can wire the path that best fits your pipeline.

async function getLatestTMT() {
  const url = "https://indices-api.com/api/latest?access_key=YOUR_API_KEY";
  const res = await fetch(url);
  if (!res.ok) throw new Error("HTTP " + res.status);
  const body = await res.json();

  // Defensive parsing against the documented envelope
  const d = body && body.data ? body.data : body;

  if (!d.success) throw new Error("API error: success=false");

  const ts = d.timestamp;          // Unix seconds, UTC
  const asOfDate = d.date;         // YYYY-MM-DD
  const base = d.base;             // "USD"
  const tmtPerUsd = d.rates.TMT;   // TMT per 1 USD
  const usdPerTmt = d.rates.USDTMT;// USD per 1 TMT

  return { ts, asOfDate, base, tmtPerUsd, usdPerTmt };
}

async function getDailyTMTFluctuation(startDate, endDate) {
  // Use the fluctuation endpoint for day-over-day change fields.
  // See parameter details in the docs; end_date cannot be "today" if data hasn't settled.
  const params = new URLSearchParams({
    access_key: "YOUR_API_KEY",
    start_date: startDate,  // e.g., "2026-10-23"
    end_date: endDate,      // e.g., "2026-10-24"
    symbols: "TMT"
  });

  const url = "https://indices-api.com/api/fluctuation?" + params.toString();
  const res = await fetch(url);
  if (!res.ok) throw new Error("HTTP " + res.status);
  const body = await res.json();

  // Inspect fields based on the fluctuation schema:
  // success, fluctuation, base, start_date, end_date, and rates.TMT.start_rate/end_rate/change/change_pct.
  return body;
}

(async () => {
  const latest = await getLatestTMT();
  console.log("As of", latest.asOfDate, "1 USD =", latest.tmtPerUsd, "TMT; 1 TMT =", latest.usdPerTmt, "USD");

  // Example dates; ensure they are trading days/valid calendar days and that end_date is not "today" if not settled.
  // const fl = await getDailyTMTFluctuation("2026-10-23", "2026-10-24");
  // console.log("Fluctuation payload:", JSON.stringify(fl));
})().catch(console.error);

Notes:

The latest endpoint returns a single snapshot; you will read base, date, timestamp, and rates to render your card.
The fluctuation endpoint (when queried with start_date and end_date) returns change fields for TMT that you can store or alert on. If you choose not to use the fluctuation endpoint, you can compute change yourself from a time-series query (prior close vs. current close). See more in the Documentation.

Computing “price change” correctly for TMT

You have two practical options to express a daily change for TMT, both valid depending on your UI copy and user expectation:

Change in USD per 1 TMT: Use rates.USDTMT and compare end vs. start. This is the intuitive “TMT in USD” quote.
Change in TMT per 1 USD: Use rates.TMT and compare end vs. start. This is “USD in TMT”; if your app quotes dollar costs in manat, this may be preferable.

The fluctuation endpoint will give you the appropriate start_rate, end_rate, change, and change_pct for the base you queried. Because Indices-API uses USD as base by default, make sure you are reading the exact key you want to display (TMT or USDTMT) and label it unambiguously in your UI.

Handling dates, settlement, and weekends

Currencies and macro instruments do not “trade” in the same calendar sense as equities, but daily snapshots still follow a cadence. Keep these in mind:

Timezone: Timestamps are Unix seconds and should be interpreted as UTC. Align your storage and comparisons to UTC to avoid off-by-one-day bugs.
Update frequency: The latest endpoint updates on a schedule tied to your subscription plan (e.g., up to every 10 minutes or 60 minutes). If you are building an hourly updater, budget for some jitter and add retries.
Weekends/holidays: Daily settlement may not change across weekends or holidays. It’s normal for fluctuation to show zero change between consecutive calendar days in such periods.
end_date cannot be “today”: For fluctuation or time-series requests, use a settled end_date. If you need “today so far,” treat it as intraday and display it separately from the prior-day close.

Caching, retries, and idempotency

If you poll the latest endpoint on a schedule, add a short-lived cache (e.g., 30–120 seconds) in your service layer to de-duplicate bursts. Include the response timestamp and date in your cache key so you don’t overwrite a newer snapshot with a delayed one.

For background jobs computing daily change, make them idempotent by keying the job on the date and symbol (e.g., 2026-10-24_TMT) and verifying the API’s date field before writing to your store.

Backfilling a week of TMT daily changes

If you need more than one day of changes, the time-series endpoint will let you pull a continuous daily range and compute changes per day. Alternatively, you can loop the fluctuation endpoint by day to receive explicit change fields. If you’re unsure which is better for your workload and cost profile, start with time-series for batch backfills, then use fluctuation for near-real-time day-over-day summaries. Full parameter details are in the Documentation.

Validating TMT semantics in your product copy

Because Indices-API is USD-based by default, quoting “TMT price change” can be ambiguous unless you specify the unit. Good patterns:

“1 TMT in USD: 0.2844 (−0.12% d/d)” if you use USDTMT as your display rate.
“USD/TMT: 3.5157 (+0.10% d/d)” if you use TMT (TMT per USD) as your display rate.

Consistency matters—store both rates if you need to support multiple UI surfaces, but always compute the day-over-day change on the same rate you display.

Security, key management, and environments

Store YOUR_API_KEY in a secrets manager or environment variable; never commit it to a repo.
For client-side apps, proxy calls through your backend to avoid exposing credentials.
Use separate keys or at least separate environments for staging and production; pin staging to a different cache TTL to catch integration regressions early.

Where to go next

Explore all available endpoints and response shapes for currencies and indices in the Documentation. Validate symbol availability and metadata on the Symbols page if you plan to scale your integration beyond TMT. If you need multi-cloud portability patterns for your data pipeline, see MCP.

Homepage links for quick access: Indices-API and official site.

Appendix: Netherlands Antillean Gulden (ANG) note

If your app needs to compare TMT with regional currencies such as the Netherlands Antillean Gulden (ANG), follow the exact same patterns: latest for the snapshot, fluctuation for the day-over-day change, and time-series for backfills. Confirm the ANG symbol on the Symbols page and use the USD base semantics consistently in your UI labels.

Practical checklist before you ship

Confirm symbol: TMT present in your symbol list; if dynamic, pull once per day and cache.
Parse the latest payload’s envelope: data.success, data.timestamp, data.date, data.base, data.rates.TMT, data.rates.USDTMT.
Choose a rate orientation for display (USDTMT vs. TMT) and compute change on the same orientation.
Use fluctuation for daily change fields; ensure end_date is a settled day (not “today” during market hours).
Add UTC normalization and a retry policy; cache short-lived responses to reduce thundering herds.

FAQ

Q: What’s the base currency in the responses?
A: USD. rates.TMT means TMT per 1 USD; rates.USDTMT is USD per 1 TMT. Keep your UI labels consistent with the rate you display.

Q: Can I request today as end_date on fluctuation?
A: Avoid using “today” as end_date. Use a settled end_date (typically the previous calendar day or the most recent settled day) to get stable daily change fields.

Q: How frequently does latest update?
A: It depends on your plan tier (e.g., updates can be as frequent as every 10 minutes or every 60 minutes). Build a small cache and a retry strategy in your client. See the Documentation for plan-specific details.

Q: What if I need both today’s intraday change and the prior day’s official close?
A: Use latest for the intraday snapshot and label it clearly (e.g., “as of hh:mm UTC”), and use fluctuation or time-series for prior-day close to compute the official day-over-day change. Do not mix intraday snapshots with prior closes in the same metric without clear labeling.

Q: Where can I verify TMT coverage or discover related symbols?
A: Check the Symbols page. If you are unsure about a specific code, confirm it there before coding against it.

Ready to integrate TMT daily change into your dashboard or alerting pipeline? Start your 7-day trial and get an API key here: Register. For pipeline architecture guidance and portability patterns, see MCP, and keep the Documentation open as you wire endpoints into your build.

Ready to use Indices-API?

Try it now!