What is an API endpoint? (the doors your app knocks on)

What it actually is

An API endpoint is a specific URL where a server is listening for one specific kind of request, and it does exactly one job. Think of a company’s phone system: you don’t call one general number for everything, you dial an extension. Extension 101 is billing, extension 102 is support, extension 103 cancels your account. Each extension answers differently because each one is wired to a different task. An endpoint is that extension, but for software: a URL like https://api.stripe.com/v1/payment_intents/pi_1a2b3c is wired to look up one specific payment, and nothing else.

The URL alone isn’t the whole instruction, though. The HTTP method riding along with it matters just as much. GET https://api.stripe.com/v1/payment_intents reads the list of payments. POST to that exact same URL creates a brand new one. Same address, different verb, completely different outcome. That pairing, one URL plus one method, is what people mean when they say “endpoint.”

Why your AI just did this

Your agent reaches for an endpoint constantly, in two different directions. Going out, when it wires your app to Stripe, Supabase, or any other service, it’s calling endpoints that company already built and documented (POST /v1/payment_intents to take a payment, for example). You never see or write that server code, you just call it correctly: right URL, right method, right data attached.

Going in, when your agent adds a new feature to your own app, it often creates a brand new endpoint for your own frontend to call. That’s what’s happening when it scaffolds a file like app/api/signup/route.ts and writes a POST function inside it: it just built a door on your own server, one your sign-up form can now knock on. The webhook a payment provider calls into your app later is really the same idea in reverse, an endpoint you built specifically for someone else’s service to hit.

When you’ll run into it

• A 404 Not Found when your frontend calls an endpoint that doesn’t exist yet, or the path has a typo (/api/user instead of /api/users)
• A 405 Method Not Allowed, meaning the endpoint exists but doesn’t support the method you used, a GET-only endpoint hit with a POST
• API documentation pages (Stripe, GitHub, any service) laid out as a list of endpoints, each with its method, its URL, and what it expects back
• Your agent scaffolding a new route.ts or route.js file and telling you it “added an endpoint” for something
• Testing a single endpoint by hand with a tool like curl or Postman to see the raw response, separate from your actual app

What to check

• The path in the request matches the documented endpoint exactly, including capitalization and trailing slashes
• The HTTP method is the one the endpoint expects. A GET where a POST belongs is a common copy-paste mistake
• Anything sent as JSON in the request body actually matches the shape the endpoint expects, missing or misnamed fields are a frequent cause of silent failures
• A protected endpoint receives the right auth header or API key, not just a request with no credentials attached
• The response status code, not just “it didn’t crash.” A 200 with an error message buried in the body is easy to miss

Say it like a dev

Instead of: “the API isn’t working” Say: “the POST to /api/signup is coming back with a 404, is the route file in the right folder?”

Instead of: “make it talk to Stripe” Say: “call Stripe’s endpoint for creating a payment, then handle whatever it sends back”

Instead of: “why does nothing happen when I click submit” Say: “can you check the network tab and confirm the request is hitting the right endpoint and getting a 200 back?”