About this research

Who ran it, what they are and are not qualified to say, and how to check the whole thing without taking anyone's word for it.

The short versionapinae.dev is a one-person open research project into vendor API drift, run by Utkarsh Raj Sutihar. There is no product, no funding, and no vendor involvement. Every figure published here comes from a public endpoint that is linked next to it, so the research does not rest on my authority and you should not treat it as though it does.

Who I am

I am Utkarsh Raj Sutihar, an undergraduate at the Singapore University of Technology and Design, where I am a Design & Engineering scholar. I am also president of the Singapore chapter of the International Association of Physics Students. My work sits mostly at the intersection of artificial intelligence, finance and theoretical physics.

Two earlier projects are the closest thing I have to relevant background. I forecast and optimised a $2M portfolio using Holt-Winters and portfolio theory, and I built a cost analysis of over $50M of material and supply for SLB using natural language processing to turn unstructured records into something decision-makers could act on. Both were exercises in the same thing this research is: taking a large pile of messy public or internal data and getting a defensible number out of it.

What I am not

I have never maintained a vendor SDK. I have not worked in developer relations, I have not run a platform team, and no vendor named in this research has ever employed me. I am not writing from twenty years of being paged at three in the morning.

That is a real limitation and it shapes what this project can honestly claim. I can tell you how far behind the world's SDK users are, because that is measurable from public data. I cannot yet tell you what it feels like to own that problem inside a company, which is exactly why I am interviewing engineers who do.

Why the method matters more than my CV

Because I have no standing to be believed on reputation, the research is built so that it does not need any. Every headline figure is linked to the public endpoint it came from. The full per-vendor table is published. The 38 GitHub searches behind the third finding are listed as re-runnable queries rather than described. The dataset ships as CSV and JSON under CC0, and the medians quoted in the report are computed from those files rather than typed in by hand.

If I am wrong, you can prove it in an afternoon with a laptop and no special access. That is the standard I want to be held to, and it is the only one I think a project like this is entitled to.

What this project is not

Not a product. There is nothing to buy and nothing in beta. If that changes, this page will say so before anything else does.
Not vendor-sponsored. No vendor named in the research was contacted for it, participated in it, or saw the findings before publication. Vendor names appear as measured subjects and nothing else.
Not a census. The measurements cover the JavaScript ecosystem through the public npm registry. That is a large and representative slice of the problem, not the whole of it.
Not finished. The numbers are point-in-time measurements taken in early August 2026 and will drift as vendors publish. The report's limits section lists what the data does not yet show.

Corrections

If you find an error, I would rather hear it than not. Email [email protected] with the figure and what you think it should be. Corrections that change a published number get recorded on the report itself with the date, not quietly edited in.

Talking to me

I am interviewing people who own third-party integrations, and the developer relations and API people on the other side of the same problem. Twenty minutes, no demo, nothing to sell. If that is you, there is a booking link on the homepage.

Last updated 13 August 2026.