API integration, and the part that is not the integration

The difficult part of an API integration is not making the call but handling refusal: rate limits, authentication that expires, errors that arrive as a successful response, and the browser rules that make code working in a terminal fail in a page.

API integration usually means writing a request, reading a response and mapping some fields. That part is genuinely easy now, and it is not where integrations fail.

Works in the terminal, fails in the browser

A request that succeeds from your machine can be blocked in a page, because the browser asks the other server whether your origin is allowed and refuses if it does not say yes. Nothing in your code is wrong. This is the single most common reason a generated integration works while being demonstrated and not when deployed.

A 200 is not a success

Plenty of APIs return a perfectly good HTTP response containing an error in the body, and plenty of clients check the status and stop there. Read the payload. A response that parses is not the same as a response that answered your question, and the gap between them is where wrong numbers enter quietly.

Rate limits are the normal case

Anything you call in a loop will refuse you eventually, and the refusal is often vague rather than explicit. Treat a rejection as information rather than as an error to retry: read what it says, back off, and stop rather than hammering. A client that retries into a limit turns a pause into an outage.

Credentials are the part that surprises people later

A key in front-end code is a public key, whoever wrote it. If the integration has to run in a browser, the call belongs on a server you control, or the endpoint has to be one that is safe to call without a secret. Deciding that at the start is cheap and retrofitting it is not.

The version worth building first

One call, from the place it will actually run, with the failure path written before the happy path. If it can survive being refused, being rate limited and being given nonsense, the rest is mapping fields. The figures below are that call, made from the server, through an endpoint that needs no key.

Live, right now, on this page

Market	Price	Funding	24h volume
BTC	$84,587.50	-0.0034%	$366,742,771
ETH	$2,515.85	0.0013%	$279,834,512
SOL	$108.66	0.0013%	$77,135,244
HYPE	$81.41	0.0013%	$11,900,787

Read from a live market as this page rendered, through a public endpoint that needs no key. Read at 2026-10-21 17:39 UTC; accurate as of that time and not afterwards.

Describe something and watch it get built.

Open the builder, or start from a working app and change it.

Common questions

Why does an API call work in the terminal but fail in the browser?

The browser asks the other server whether your page's origin is allowed and refuses if it does not say yes. Nothing in your code is wrong, and it is the most common reason a generated integration works in a demo and not once deployed.

Does a 200 response mean the API call succeeded?

Not necessarily. Many APIs return a perfectly good HTTP response with an error in the body, and many clients check the status and stop. A response that parses is not the same as one that answered your question.

Is it safe to put an API key in front-end code?

No. A key in front-end code is a public key, whoever wrote it. If the integration runs in a browser, the call belongs on a server you control, or the endpoint has to be one that is safe to call without a secret.

See the number itself

Pages that read a live market and show what they read, updated while you look at them.

Taiwan Semiconductor Manufacturing stock, live, through the tokenised share, every figure on it comes from one public API call, which is what this page is teaching.
Cisco Systems stock, live, through the tokenised share, the same integration against a second symbol, so you can see what changes and what does not.
AbbVie stock, live, through the tokenised share, a price series turned into a chart and six derived signals, from a single endpoint.
UnitedHealth Group stock, live, through the tokenised share, a live read with its own failure state, which is the part most integrations skip.
Oracle stock, live, through the tokenised share, a continuously quoted equity, useful for testing how your client handles a feed that never closes.
Broadcom stock, live, through the tokenised share, a second continuous feed, for checking your polling and cache behaviour against.
Netflix stock, live, through the tokenised share, a continuously quoted feed with a real failure state to handle.