IDX, NEPSE, LuSE, CSE, HKEX CCASS holdings and the India IPO book, returned as JSON from one request API. Closing prices, announcements, index history and subscription multiples, read from the public exchange site at the moment you call.
Yesterday's IDX stock summary, the LuSE closing price sheet, a NEPSE floor sheet, a Colombo market page. Four portals, four formats, one analyst copying cells into the model.
QIB demand lands in the last afternoon. The PM wants the multiple by category, now, and the answer is a browser tab somebody has to keep refreshing.
Who moved stock into which participant last week is disclosed. It is also one stock code and one date per search, so tracking a watchlist is an afternoon of clicking.
Each line below is one hosted function with a stable ID. Call it, get JSON. This is the full inventory, not a sample.
Pick a function. IDX daily stock summary, LuSE closing prices, mainboard IPO subscriptions, a CCASS shareholding lookup. Each has an ID and a short list of variables.
Start a run. We open the exchange's public site in a real browser on our side, navigate the portal or the search form, and read what it shows.
Load the result. Rows come back as JSON with a fetch timestamp. Put it on a schedule you control: after each close, or hourly while a book is open.
When a portal changes, the function is ours to fix. The ID you call stays the same.
Enter the offer size, the category reservation and the bids received. You get the multiple for QIB, NII and retail, plus the overall book. Or press replay to watch a simulated three-day book build fill in, hour by hour, the way the mainboard subscription endpoint would report it.
The arithmetic is the easy part. Having the bid numbers in a table at 15:00 on day three, without a person refreshing a tab, is what the API is for.
"Our coverage universe is exactly the names the terminal carries thin or late. I used to open four exchange portals before the morning meeting. Now the closes are already in the model when I sit down, and I spend that hour reading announcements instead of downloading them."
"During a book build I poll the subscription endpoint every hour and post QIB, NII and retail to the desk channel. Nobody refreshes a tab on day three any more."
"I retired a folder of PDF parsers for the Lusaka closing sheet. The honest framing helped too: it is a request API and they say so, which made the internal sign-off simple."
No. Frontier Tape is a request API. When you call an endpoint, we open the public exchange site or portal in a browser and return what it shows at that moment. It is not a licensed real-time feed from any exchange and it is not a push stream. If the source page is delayed, the data you receive carries the same delay.
As fresh as the source page at the time of your call. Each response carries the time we read it. A run takes as long as a browser needs to load and navigate the page, so design for scheduled pulls after the close or polling during a book build, not for tick-by-tick trading.
We return what the public site displays; we do not grant any rights over the underlying data. Exchanges set their own terms for commercial use and redistribution. If you resell or republish, check those terms and obtain the licence you need from the exchange.
We do not run an archive. Where the source itself exposes history, the endpoint returns it: NEPSE index history, ShareSansar index history and CCASS lookups by date are examples. For everything else, schedule the call and store the results on your side.
The function is ours to repair, and it keeps the same ID. Until a fix lands a call can fail, so add retries and alerting the way you would for any upstream source.
Yes. Tell us the exchange and the page or form you rely on. If it is publicly reachable in a browser, it can usually be turned into an endpoint.
Frontier Tape runs on Notte. Each endpoint is a hosted Notte function, and you call it through the Notte API with your own key.
Start with the one portal that costs you the most time. Pull it once, compare it to your sheet, then schedule it.