The word "API" gets treated like a developer term — something that belongs in a conversation about code, not a conversation about GIS workflows. But the concept is simpler than the acronym suggests, and understanding it changes how you think about your own AGOL data.
Because here's the thing: every Feature Layer you've ever published to ArcGIS Online has been a live API since the moment you created it. You didn't have to do anything to make that happen. ESRI built it for you automatically.
What an API Actually Is
API stands for Application Programming Interface. The word that matters is interface.
An interface is a defined point of contact between two things. A light switch is an interface — you don't need to understand the wiring inside the wall, you just need to know that flipping the switch turns the light on. The complexity is hidden. The interaction is standardized. Push up, light on. Push down, light off.
An API is that same idea between software systems. A defined point of contact. You send a specific kind of request, you get back a specific kind of response. Every time. Predictably. Without needing to understand what happens in between.
Websites vs APIs
A website is designed for human eyes. When your browser requests a webpage, the server sends back HTML — formatted text, images, layout instructions. The browser renders that into something readable. The content is designed to be seen.
An API is designed for software. When code requests data from an API, the server sends back raw information — usually in JSON format, which is just structured text. No layout, no formatting, no presentation layer. Just the data.
Same internet. Same underlying request mechanism. Different intended audience.
When you open ArcGIS Online in a browser and look at your shelter layer on a web map, you're seeing a website render the API's data into something visual. When your JavaScript code calls queryFeatures(), it's talking directly to the API — bypassing the visual presentation layer entirely and just getting the data.
Your Feature Layer's URL Is the API
When you publish a layer to AGOL, ESRI creates a URL like this:
https://services.arcgis.com/{your-org}/arcgis/rest/services/Shelters/FeatureServer/0
Try this right now: open any of your hosted Feature Layers in ArcGIS Online, scroll down to find the REST URL, and paste it into your browser. You'll see a page full of JSON — your layer's metadata, field definitions, and information about how to query it.
That page is the API responding to your browser's request. Your browser sent a request to that address. The server sent back data. That exchange — request in, response out — is an API call.
You've been looking at your data through ESRI's map interface, which is a polished presentation layer built on top of this API. But the API was always there underneath, waiting for anyone who knew to ask.
Adding a Query
The URL above returns metadata. To get your actual features — the points, lines, or polygons with their attributes — you add /query to the end and include some parameters:
https://services.arcgis.com/{org}/arcgis/rest/services/Shelters/FeatureServer/0/query
?where=STATUS='OPEN'
&outFields=NAME,CAPACITY,OCCUPANCY
&returnGeometry=true
&f=json
Paste that in a browser (with your actual org ID and a valid where clause) and your features come back as raw JSON. Every open shelter, with the fields you asked for, with their coordinates.
That's all queryFeatures() does in code — it builds that URL for you and fetches it. The result is the same data you'd get from the URL directly, just returned as a JavaScript object you can work with instead of a page in a browser.
The Three Parts of Every Query
Every request to your Feature Layer API has three basic parts:
Filter (which rows): A SQL-style where clause. 1=1 means all records. STATUS = 'OPEN' means only open shelters. CAPACITY > 500 AND STATE = 'FL' means large shelters in Florida.
Fields (which columns): An outFields parameter. ['*'] means all fields. Listing specific fields reduces the size of the response — matters on slow connections in disaster deployments.
Geometry (include coordinates): returnGeometry=true includes the location of each feature. If you only need a count or a table of numbers, set this to false.
const result = await featureLayer.queryFeatures({
where: "STATUS = 'OPEN'",
outFields: ['NAME', 'CAPACITY', 'OCCUPANCY'],
returnGeometry: true
});
The response is a collection of features — each with its attributes and its location. That's it. The entire API interaction.
Why This Reframes What AGOL Is
Most GIS professionals think of ArcGIS Online as a place to manage and view maps. That framing is accurate but incomplete.
AGOL is also a data service. Every layer you publish there is simultaneously available as a live API that any tool can query — JavaScript in a web browser, Python on a server, n8n in an automation workflow, or a direct URL in a browser. You've been building and maintaining a data API every time you've updated your hosted layers.
The practical implication: your AGOL data isn't limited to what ESRI's interface can show. Anything that can make a web request can ask your layers for data. MapLibre can render it. Deck.gl can visualize it. A Claude AI model can reason about it. A Python script can process it.
ESRI built the hosting and the API automatically. What you do with it is your choice.