Build an API in 2026 & make SERIOUS money (full guide / beginner friendly / examples)

What's going on, guys? This is Oliver, formerly from Response AI and a few other software tools that I've since exited and now running broell.dev, which is a course where I teach people how to vibe code and make money from software, and running uh papers.com, which is an AI content agent for LinkedIn, uh Twitter, and Reddit. So in this video um I wanted to talk about the sort of new landscape of 2026 and specifically why being an API is the most profitable sort of business model for SAS uh in 2026. Um so basically AI agents they don't sort of browse websites right they call APIs. So, I want you to I want you guys to sort of think about how you can make money in 2026, not by being um just a standard sort of like software, but rather how to build an API. Now, if you guys aren't familiar, obviously um there's a few other sort of older videos where I talk about APIs. An API is basically access to data. Um sort of access to other people's tools. Okay? So in the simplest way to put it, let's say you wanted to access um the most recent um scores of um you know football matches. You can access an API which has real-time data for the football matches and their results, right? The same thing applies to APIs for the stock market. You can just, you know, um access the current sort of stock uh um stock sort of prices with an API. The same thing applies to crypto. There's thousands of APIs. There's literally millions of APIs. There's APIs for weather. There's APIs um for recipes, for cakes or or you know, spaghetti. There's everything, right? The single fact that AI agents are using APIs um is reshaping which businesses sort of print money and which ones get sort of um disintermediated. So, in other words, the ones that kind of just don't get sort of a fair share of u of sort of attention. If your product has an API, you're a tool that agents can use. And obviously, we're going down the route where agents are sort of building everything. Being an API provider in 2026 is very sticky because if you can get um stuck in with someone's agents and the way someone builds with AI, then you'll have long-term customers. The entire premise of AI agents is autonomy. So, they research, they decide what APIs to use, and they execute. But they can only execute through structured interfaces. So an agent can't click a button. It can't navigate through your on boarding. It can't drag and drop things. It can only sort of like query an endpoint. So it can ask this API what the weather's going to be tomorrow. It can ask the API what the um what someone's email is. You know, it can ask these different kinds of things. And every AI agent framework in production today works the same way. The agent just gets a task, it picks a tool, and then it calls an API. So uh Claude's tool use system opai all of them resolve to the same thing. They just make requests to an API. Now API first businesses have become the default building blocks for autonomous workflows. So in other words pretty much every tool that you like to use is calling an API. So let's say cursor right cursor all cursor does I say all it does is it's an incredible tool. I use it every day. But cursor just calls the APIs of Claude and GPT to write code and then it just sends the code to your front end. That's a very very simplistic version of what it does. If your service is callable and you're in the stack, then the agent is going to keep you in that stack and the person who's building that software is going to keep you in that stack. Right? So, who's making money right now? So, screenshot one is an example. I love the um founder Dimmitri. Uh it's a solo founder app. So it's built by Dimmitri only and it's an API that renders screenshots. So you send a URL like apple.com and you get an image of the website back. It crossed thousands tens of thousands in MR by doing one thing well. The product integrates with Zapia make pipe dream N8 whatever it may be. And now any AI agent that needs screenshots the AI agent will recommend that you use screenshot one. Every new automation platform that ships becomes another distribution channel. The founder doesn't need to build integrations. The API is the integration. Posties started an open-source social media. So they built a public API and a dedicated client for AI agents, right? And it's now at $60,000 a month, right? So there what they offer basically is access so that you can post to social media and it's just an API and it's one protocol and thousands of agents are choosing posties to um build apps that are basically you know posting to social media. So let's put this into to practice. If you asked an AI tool now like cursor or lovable I want to build an app that helps me helps me post um to social media. it is likely going to choose posties as the API of choice. If I said I want to create um an app that helps people gather screenshots of an app of like websites, right? It's probably going to choose screenshot one. So, do you guys see how this works? Right? You are creating apps that are going to be uh sort of like helpful to AI agents when the AI agents asked to achieve a task. Resend, which I use every single day, is an email API. So simple endpoint they shipped um like AI agent sort of like help desk basically so that when you ask for help in cursor with email um cursor knows exactly what to do and every developer wiring up their tools to resend um is growing with resend and paying them every single month. I pay resend every single month. Right? Now, let's see. Let's go even further. Right? Let's say a tool I want to build is an app that um basically monitors people monitors people's websites every day and then sends them an email every day with a digest of what has changed on that website. How am I going to get the screenshot? Right? Probably going to use screenshot one. How am I going to send the email every day that updates them about the changes to that website? I'm probably going to use resend. So that is an app that is built off of two APIs and the APIs I'm just going to be paying every single month to run my tool and the further I grow the more I pay them. Now that follows on to why API stickiness beats SAS stickiness. So traditional SAS comes from workflow lockin, right? Users learn your UI, they build habits around it, they store data that's real, but it's quite fragile. a better UI comes along or it's cheaper or it's funner or it's cooler and people switch. API stickiness is structural. It's code level lockin. So when a developer integrates your API into their agent workflow, that integration lives in their codebase, right? And it's tested, it's deployed, and ripping it out means rewriting code, retesting, redeploying, etc. Now multiply that by a thousand. When your API becomes the default tool that agents use to build apps, you're embedded in thousands of code bases. So every custom agent built by a developer um is using your API. Now the switching cost isn't emotional, right? It's just engineering hours. That's a much harder cost to justify when the current solution works absolutely fine. I use resend as an API to send my users for paper schedule emails every day. I think, yeah, there's other things. There's other things I could use, but I have to go back into my codebase and recalibrate everything and test things. And what if the new system I use doesn't doesn't work? API revenue scales with usage, right? So, the more users I get, the more resend emails I send. The more users I get, um, the more screenshots I have to take, the more users I get, the more times I have to query the recent football scores. You see how this works? It runs the workflow every time and every time it runs it calls your endpoint and that's what makes it sticky. Your customer isn't a person clicking a dashboard anymore. Your customer is a line of code inside a system. That line of code doesn't churn and cancel you because it saw a competitor's ad or because it likes the look of a different app. It's stuck in the code and that's why APIs are so important. So let's talk about this, right? What could you actually build as a solo founder? Right? So before getting into the technical process here are some API products that a solar founder could realistically ship and someone who doesn't really understand code right and inside um the description guides is going to be fullcale prompts on how to build these right so on top of this when I've explained what APIs you could build I've also given examples of really profitable and popular APIs that are already doing this right on the right so PDF generation API you send um a file and you get back a styled PDF. Every agent now that creates reports, invoices, receipts, proposals, etc. needs this, right? And the pricing is per document generated. So one credit is, you know, one document and you, you know, pay per credit or you pay per 100 credits, whatever it may be. Social proof screenshot, right? You send a tweet URL or LinkedIn post and you get back a beautiful screenshot image. Content creators and scheduling agents need this constantly and they put um social proof on their websites etc. and you just price per screenshot. We talked about this earlier. So there's plenty of um uh companies that are APIs that just monitor um the changes to a website, right? So website change monitoring API, you send a URL to your API, the API checks periodically and returns some news when the content changes. agents doing competitor research, price monitoring, compliance checking, they need this, right? And pricing is just per monitored URL. Text to audio API. You send text and you get back an MP3, right? Every content repurposing agent, podcasting tool, everything. All of these workflows need them. And there's hundreds of those tools being built. And the price is just per minute of audio. Email verification API. You send an email address. This is very easy to build. and you get back the deliverability status. So every outreach agent, every time a new cold email agent runs, all of those workflows need these. So you could build one of them. Then the most important one here is email retrieval. So literally companies making millions with this exact thing, right? So a user sends a company domain. So apple.com and the API just gets a list of employees and their emails back, right? Zoom Info makes millions and is worth billions. It's listed on the NASDAQ. Now, here's the actual process, right? This assumes you have limited coding experience and the stack is just cursor, superbase, versel. Total cost to get to production is basically zero, right? You set up account on cursor, superbase, and versel, right? And versel is where the API gets deployed and gets public URL wherever it may be. Step two is scaffold the project in cursor. It takes one hour, right? And you start this with a prompt. This is in the description for you guys to copy. But I want to build a simple API product using Nex.js and Versell. The API does one thing. The text stack is Nex.js, TypeScript, Versel, Superbase. I need a project, an API key, a Superbase table um called API keys, a Superbase table to track users usage, middleware that checks the API keys, increments usage, rejects limits, and the actual endpoint logic that processes the request in a simple landing page. You don't have to write any code yet. You review what comes back and you push back on anything that looks over complicated. You just want the minimum number of files, right? For a simple API that just calls the weather or something that could be five to eight lines, right? Sorry, five to eight files. Once the architecture looks right, tell cursor to generate the code and it'll just create the files, right? You review each one. You don't need to understand every line, but you should understand the flow. Go to your Superbase dashboard and you open the SQL editor. Ask cursor to generate the SQL for your tables. So again this prompt that you can just copy paste is going to be in the description. Generate the SQL table statements for the API keys and uses lodge logs and then just go from there. You copy the SQL that cursor gives you and you paste it into Superbas's SQL editor. Now this is where the actual work happens. You tell cursor to implement the endpoint logic. So implement the APIV1/creenshot endpoint. The input is a JSON body with URL example. Right? So let's assume we're building something like screenshot one. The output is a PNG of the um endpoint, sorry, a PNG of the website the user gave you and you just use puppeteer to render the page, right? You wait for the network to be idle. You capture the post um capture the image of the website and then you just return it to the user. You deploy this to Versell in 15 minutes, right? You just say to cursor, help me initialize a git repo and then walk me through the steps to get it on Versell. Then you just create a very very simple landing page that tells people what the API does. So for example with screenshot one is a screenshot API. All you have to do is sign up and then you just start sending it the list of your um websites that you want to screenshot. You build a clean landing page explaining what the API does, the pricing, which is going to be very simple for an API because just per credit, and you style it with Tailwind or you style it with um you know um shad CN, and then it's just one page. And then from there, you set up the superbase authentication so people can log in and you just use stripe checkout as payment. So ask cursor to implement a checkout route that creates a checkout session for the pro tier and a web hook handler that upgrades the users upgrades the users sorry uh request limit in superbase when payment succeeds then this matters more than you think because the agents that are going to be looking for your API to use um are going to need documentation to read it right so you ask cursor to generate a documentation page explaining how to get the API keys how the endpoint works and what your API actually does and then you validate before you polish. At this point you have a working API, a landing page, stripe billing and docs and the total time is probably less than a day to be honest and the total cost is between 0 and $20. Don't spend another second on polish until you validate match. You post the landing page in relevant communities. You see, I built an API that does this and you offer 500 free API calls to the first 50 signups and you see if anyone actually uses it. signal you're looking for is are developers integrating your API into their workflows? If yes, you have something and if they sign up and never call the endpoint, the product isn't solving a real problem. Now, the business that will dominate in this economy aren't the ones building agents. They're the ones building the APIs that agents will use and cannot function without. Screenshot one basically is one person, right? Resend started as a small team building a developer experience around email and posties is an open- source um tool with an API right the bar for entry is low all of these or most of these were built by solo founders just like you and me and the compounding potential is high so you build a simple API you make it reliable you write clean docs you get embedded inside coding flows and then that is the position that you'll take to make money if you guys have any questions let me know but in the next couple of videos I'm actually going to be building an API to show you guys what I mean by this. And obviously um I'll obviously post in the uh description as well maybe 10 API ideas that we could build together and I'll go from there. If you have any ideas just let me know. But I'll speak to you soon.