What Is an API Endpoint? The Door Your Agent Built Into Your App

Your coding agent said it "added an endpoint," you saw the feature work, and you moved on. That endpoint is now a door into your app that anyone on the internet can walk up to and knock on, and you have no idea what happens when they do.

That gap, between "the feature works" and "I know who is allowed through this door," is where a lot of AI-built apps quietly go wrong. Not because the agent wrote bad code. Because the most important thing about an endpoint, who can call it and what it hands back, is a decision, and nobody made that decision out loud. So the agent made it for you, in favor of whatever got the demo working fastest.

If you have been building with Cursor, Claude Code, Lovable, or Replit and you have never been quite sure what "an API endpoint" actually is, this post is for you. The hypothesis is simple: an API endpoint is a public door into your app, and the behavior of that door, who is allowed through and what they get, is an acceptance criterion you specify, not a default you inherit.

#What an API endpoint actually is

Start with the plain-language version, the one the docs bury under jargon.

An API is the set of ways other programs are allowed to talk to your app. An endpoint is one specific door in that set: a single URL, paired with an action, that does one job. When your frontend loads a user's orders, it is knocking on a door like GET /api/orders. When someone signs up, the app knocks on POST /api/users. Each of those is an endpoint. The developer community has a good analogy for the relationship. As one widely shared explainer put it:

You can think of an API as a building, and endpoints are the doors to enter that building. Each endpoint corresponds to a specific function or data point in the API.

That building-and-doors picture is the whole mental model, and it is worth holding onto, because it makes the security question obvious in a way the word "endpoint" never does. A building can have a front door with a receptionist who checks your badge, and it can have a loading dock around the back that someone left propped open. Both are doors. Both let you into the building. Only one of them is watching who comes through.

Here is the part that surprises non-technical builders. When your agent "adds an endpoint," it is adding a door to the public building that is the internet. By default, that door is reachable by anyone who knows the URL, not just the polished button in your app that calls it. Your login screen guards the front of the app. It does nothing for the loading dock your agent added at POST /api/admin/delete-user unless someone specifically decided that door needs a badge check. IBM's definition is precise about what an endpoint is, a digital location where an API receives requests, usually a URL. What the definition leaves out is the thing that matters most to you: a location where an API receives requests is, by default, a location where it receives requests from anyone.

#Why AI builders trip over this specifically

Search "what is an API endpoint" and you get IBM, Postman, Cloudflare, Contentful, GeeksforGeeks, and a ten-year-old Reddit thread. Every one of them explains the mechanics correctly. None of them is written for the person whose situation is new: someone who did not write the endpoint, cannot fully read it, and only knows it exists because the agent mentioned it in passing.

That is the actual problem. In the old world, the person who created an endpoint understood it, because creating it required understanding it. You had to know what a route was, what an HTTP method was, and what "authenticated" meant, or the code would not run. The knowledge and the artifact came together. AI severed that link. Now the endpoint can exist, and work, in the hands of someone who has never heard the word "route." The door gets built. The understanding of who should be allowed through it does not come automatically bundled in.

Andrej Karpathy described the general version of this when he coined vibe coding: you "fully give in to the vibes" and "forget that the code even exists." Forgetting the code exists is fine for a weekend toy. The trouble is that the code includes doors, and a door you forgot about is a door nobody is watching. The agent will happily generate an endpoint that returns every user's data, or accepts a request from anyone, or triggers a destructive action without checking who asked, because the fastest path to a working feature is a door with no lock, and you never said the door needed one.

Consider the difference between two ways of asking for the same feature.

Vague: "Add an endpoint to update a user's profile."

Specified: "Add a PATCH /api/users/:id endpoint that updates a user's profile. Only the logged-in user may update their own profile, never another user's. A request from user A trying to update user B's profile must be rejected with a 403, not silently allowed. Requests with no valid session must be rejected with a 401."

Same door. The first version leaves the lock, and the identity check, and the failure behavior entirely up to the agent's default, which is usually "make it work in the demo." The second version turns the door's security from an invisible assumption into a written rule you can test. And you can test it without reading a single line of the code behind the door: log in as user A, try to change user B's profile, and confirm you get rejected. That is a check anyone can run. "Is the authorization logic correct?" is not.

#The reframe: an endpoint's behavior is a criterion, not a default

This is the same move we made when we wrote about row-level security: the hole that keeps showing up in AI-built apps is not a coding mistake, it is an unspecified rule. A missing auth check on an endpoint is exactly that. The endpoint's job is not just "return the profile." Its full job is "return the profile, but only to someone allowed to see it, and reject everyone else with a clear failure." The second half of that sentence is the part that never gets written down, so the agent ships the first half and the door hangs open.

Reframing it this way changes what you are responsible for. You are not responsible for writing the auth code; the agent can do that. You are responsible for stating the rule the door must obey, and then verifying the door obeys it. Every endpoint your app exposes has four questions attached to it, and every one of them is a decision you can make in plain language:

Who is allowed to call this door, anyone or only a logged-in user? Whose data can they touch, only their own or everyone's? What is this door allowed to do, read something harmless or delete something permanent? And when someone who should not be allowed knocks, what happens, a clean rejection or a silent success? Answer those four for each endpoint that handles real data, and you have written the acceptance criteria for the most dangerous part of your app, the part that faces the open internet.

There is a real trade-off worth naming, because pretending otherwise would be dishonest. Not every endpoint needs a fortress. A public endpoint that returns your marketing site's blog posts is supposed to be open to everyone; adding an auth check there would be wasted work and a worse product. The skill is not "lock every door." It is knowing which doors lead to a user's private data or a destructive action, and specifying those. The blog-post door can stay open. The delete-account door cannot. Telling them apart is judgment, and judgment is exactly the part AI does not do for you.

#Where this fits in the loop

This is the gap BrainGrid is built to close. You describe the feature in plain language, and the Planning Agent turns it into a requirement with explicit acceptance criteria, including the ones you would otherwise leave in your head: which endpoints this feature adds, who is allowed to call each one, whose data they can reach, and what happens when an unauthorized request arrives. "Only the profile's owner can update it; anyone else gets a 403" becomes part of the standard the Builder Agent builds against, whether that build runs in BrainGrid Cloud or in your own GitHub repo through Claude Code, Cursor, or Codex over MCP.

That is the loop: Plan the door's rules along with the feature, Build against them, Verify each one with evidence, Repeat. An endpoint that leaves the door open does not quietly pass, because "unauthorized requests are rejected" is written down as a criterion, and a feature is not done until every criterion is verified with evidence. Code review tells you the code behind the door is well-written. Verification tells you the door actually rejects the people it should. Those are different questions, and for an endpoint facing the internet, only the second one keeps your users safe.

#What this means if you are building right now

If your agent added an endpoint this week, do one thing before you ship: name every door the feature opened, and for each one, answer whether it touches private data or does something you cannot undo. For those doors, write the rule down as a criterion, "only the owner can call this, everyone else gets rejected," and verify it the only way that counts. Log in as one user, try to reach another user's data or trigger the action as someone who should not be allowed, and confirm the door slams shut. If it does not, you found the open loading dock before an attacker did.

The uncomfortable truth underneath this is the same one that runs through every honest conversation about building with AI. The agent is not making your security decisions badly. It is making them silently, in favor of whatever demos fastest, every time you leave them out of the spec. An open endpoint is not a mysterious bug in code you cannot read. It is a door whose rules you never wrote. Write the rules, make them criteria, and check them. For the mechanics of reviewing what your agent ships, we wrote about reviewing AI code as a non-engineer, and about how to write acceptance criteria an AI agent can actually verify.

#FAQ

#What is an API endpoint, in simple terms?

An API endpoint is a single URL, paired with an action, where your app receives a specific kind of request. If your API is a building, each endpoint is one door into it, and each door does one job: GET /api/orders returns a user's orders, POST /api/users creates a new user. Your app's frontend calls these endpoints to load and save data. The important part for a builder is that an endpoint is a public door on the internet by default, reachable by anyone who knows the URL, not just by the buttons inside your app.

#What is an API endpoint example?

A common example is GET /api/users/123, an endpoint that returns the profile for the user with ID 123. The GET part is the action (read something), and /api/users/123 is the address (the door). Other everyday examples: POST /api/login to sign in, POST /api/orders to place an order, DELETE /api/posts/45 to remove a post. Each combination of an action and an address is a separate endpoint with its own job, and each one needs its own answer to the question "who is allowed to call this?"

#What is the difference between an API and an endpoint?

An API is the whole set of rules for how programs can talk to your app; an endpoint is one specific door within that set. Think of the API as a building and the endpoints as the individual doors, each leading to one function or piece of data. You do not "call an API" so much as call one of its endpoints. The distinction matters for security because you do not secure "the API" in one move; you decide, door by door, which endpoints are open to everyone and which require a logged-in, authorized user.

#What is the difference between an API key and an endpoint?

An endpoint is the door (the URL you send a request to); an API key is one kind of badge you might have to show at the door. The endpoint is the location, the API key is a credential that identifies who is calling. An API key typically identifies which application or project is making the request, which is different from authenticating an individual user (that is usually a login session or token). A door can require a key, a user login, both, or nothing, and choosing which applies to each endpoint is the security decision you should specify rather than inherit from a default.

#How do I find the API endpoints in my app?

If your app was built by an AI agent, the endpoints usually live in a folder like app/api, pages/api, routes, or server, and each file or route there is a door. You can also open your browser's developer tools, go to the Network tab, use the app, and watch the requests fire, each one is hitting an endpoint. But finding them is only step one. The step that protects your users is going door by door and asking who is allowed to call each one and whose data it touches, then writing that answer down as a criterion your build gets verified against.

BrainGrid is the AI Product Planner that turns your idea into a requirement with acceptance criteria, including who is allowed through each endpoint your agent builds, so your app ships with locked doors instead of open ones. Try it at braingrid.ai.