What this article covers

Nearly every business application you log into is built on an API — a structured channel the interface uses to read and write data. That API is usually the difference between a task you click through fifty times and a task that runs itself.

Your browser already ships with everything you need to see that API in action. This article shows you how to look, how to read what you find, and how to try it yourself safely on a free practice service. No development experience required.

By the end you will be able to answer a genuinely useful question about any tool your business relies on: can this be automated, and how hard would it be?

What an API actually is

An API (Application Programming Interface) is a defined way for one piece of software to ask another for information, or to tell it to do something — without a person clicking through a screen.

A restaurant is a fair model. The dining room is the user interface: menus, tables, the experience you were meant to have. The kitchen is the system that does the work. The API is the waiter — a defined set of requests the kitchen accepts, in a defined format, with a defined answer coming back.

In this analogy, API automation would represent the ability to place an order without sitting down in the dining room.

Opening the developer tools

Every modern browser includes developer tools. These allow us to look “under the hood” at what your browser is actually doing when you load a web page. This will shed light on how APIs actually work, and how we can begin using them as building blocks for automation.

1. In the browser of your choice, press F12, or right-click the page and choose Inspect. A panel opens beside or below the page.
2. Choose the Network tab to watch traffic, or the Console tab to send requests yourself.
3. In the Network tab, set the filter row to Fetch/XHR. That hides images, fonts and stylesheets, leaving only the data conversations.

Keep the panel open while you use the application. Nothing is recorded until it is open, so open it first, then click.

Telling whether an application uses an API

With the Network tab open and filtered to Fetch/XHR, use the application normally — open a record, run a search, save a change.

Each line that appears is one request the page made behind the scenes. If lines appear as you click, the application is API-backed. That is the entire test.

An older application behaves differently: you will see full page reloads rather than small data requests, with the information baked into the page markup. Those systems can sometimes still be automated, but it is harder, more fragile, and rarely worth it.

Reading a single request

Click any entry to open its detail view.

• The address. Paths containing /api/, /rest/, /graphql, or a version marker like /v1/ point to a deliberate, structured API rather than incidental page traffic.
• The method. GET reads. POST creates. PUT and PATCH update. DELETE removes. Click Save, watch a POST fire, and you have just seen the save happen.
• The status. 200s succeeded. 400s were rejected — 401 and 403 are permission problems, 404 means not found. 500s mean the far end broke.
• The Response tab. The answer the server sent, usually JSON: structured names and values. If the data on your screen appears here in tidy fields, it is genuinely available programmatically.
• The Payload tab. On a write, exactly what your click sent — the fields the system actually cares about, in the shape it expects.
• The Headers tab. The envelope: content type, and how the request proved who you are.

Practise safely: a free API to experiment on

Do not learn this on a production system. JSONPlaceholder is a free, public, fake REST API built for exactly this. It needs no account and no key, it serves realistic sample data, and its write operations are simulated — it answers as though your change succeeded without altering anything. You cannot break it, and you cannot leak anything into it.

Open https://jsonplaceholder.typicode.com/posts/1 (opens in new tab)in a new tab. You are looking at a raw API response — one record, as JSON, with no interface wrapped around it:

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident...",
  "body": "quia et suscipit\nsuscipit recusandae..."
}

That is the same kind of payload sitting underneath the applications you use all day.

Sending requests yourself from the Console

The Console tab lets you send requests directly, using the browser’s built-in fetch command. Stay on the JSONPlaceholder tab while you do this — requests run in the context of whatever page you are on.

The first time you paste into the Console, the browser will refuse and ask you to type allow pasting to confirm. That guard exists for good reason; see the cautions below.

Why every example starts with await

A network request takes time, so fetch does not hand back an answer — it hands back a Promise, a placeholder for an answer that has not arrived. Run it bare and the Console prints something unhelpful:

fetch('https://jsonplaceholder.typicode.com/posts/1')
// Promise {<pending>}

await means “wait for this to finish and give me the actual result”. So the first await waits for the response to arrive:

await fetch('https://jsonplaceholder.typicode.com/posts/1')
// Response { status: 200, ok: true, ... }

That is the envelope, not the letter. Status and headers are there, but the data still needs to be read out of the body — and reading the body is itself asynchronous. So you need a second await, and the inner call must be wrapped in parentheses so it resolves first:

await (await fetch('https://jsonplaceholder.typicode.com/posts/1')).json();

Read it inside-out: fetch the URL → wait for the response → parse its body as JSON → wait for that. Two awaits, every time. If you only ever remember one thing from this article, make it that shape.

If an endpoint returns something other than JSON, swap .json() for .text(). If you would rather split it across lines, this is the same thing:

const response = await fetch('https://jsonplaceholder.typicode.com/posts/1');
const data = await response.json();
console.log(data);

Reading a list

await (await fetch('https://jsonplaceholder.typicode.com/users')).json();

Ten user records come back as an array. Click the triangle beside the result to expand it. Most APIs also accept filters in the address itself, after a question mark:

await (await fetch('https://jsonplaceholder.typicode.com/posts?userId=1')).json();

That returns only the posts belonging to user 1. Being able to ask a system for precisely the slice you need — rather than exporting everything and filtering by hand — is most of what makes automation worthwhile.

Writing something

A write carries more parts. This one is simulated by JSONPlaceholder, so it is completely safe to run:

await (await fetch('https://jsonplaceholder.typicode.com/posts', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    title: 'Test record',
    body: 'Created from the browser console.',
    userId: 1
  })
})).json();

The response comes back with "id": 101 — the identifier the service would have assigned. Each part earns its place:

• method: 'POST' — This is the key that makes this a “write” operation. Without this, fetch defaults to GET and your body is ignored.
• headers — Content-Type: application/json tells the server how to interpret what you sent. Omit it and many APIs reject the request.
• body: JSON.stringify({...}) — the body must be a JSON string, not an object. Forget JSON.stringify and you literally transmit the text [object Object]. This is the single most common mistake.

An update to an existing record is the same shape with method: 'PATCH' and an id in the address:

await (await fetch('https://jsonplaceholder.typicode.com/posts/1', {
  method: 'PATCH',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ title: 'Updated title' })
})).json();

Let the application write the request for you

You rarely have to guess the correct shape. In the Network tab, right-click any captured request and choose Copy → Copy as fetch. The browser hands you a complete, working snippet with the exact address, method, headers and body the application itself used.

That is the most valuable trick here. Rather than reverse-engineering an API from documentation, you perform the action once in the interface and copy precisely what it sent. On a real system, treat what you get as read-only reference material until you have read every line of it — see the cautions below.

When it does not work

• Promise {<pending>} — the outer await is missing.
• A CORS error — the browser blocked a request to another site’s API. Practice APIs like JSONPlaceholder allow it deliberately; production APIs may not, by design. It means “not from a browser tab”, not “you did it wrong”.
• 401 or 403 — not signed in, session expired, or insufficient permission.
• 400 — the payload shape is wrong. Compare it field by field against a real request captured from the interface.
• 200 but nothing changed — a field name was probably misspelled and silently ignored. Loosely validated APIs do this often, which is why a success code alone is never proof.

Other signals worth checking

• Published documentation. Search the vendor’s site for “API documentation” or “developer portal”. A public, versioned, documented API is a far stronger foundation than one you found by watching traffic.
• A settings page for API keys or tokens. If the product lets you generate credentials for integrations, the vendor supports API use as a feature.
• An existing integration marketplace. If it already connects to other platforms, the plumbing exists.

An API visible in the Network tab but absent from the vendor’s documentation is an internal API. It works, but the vendor has promised nothing about keeping it working, and it can change without warning in any release. That distinction matters enormously before you build a business process on top of it.

Important cautions

Looking is safe. Acting on what you see is not always safe.

Never paste code into the Console because someone told you to

Code run in the Console acts as you, with your session and your permissions. Attackers know this. A common scam is to persuade someone — through a support chat, a forum post, a video description, or an answer from an AI assistant — to paste a “quick fix” into the Console. That snippet can steal a session, exfiltrate data, or install a persistent back door, and the browser will not warn you, because you authorized it.

This is why the allow pasting prompt exists. Run code you wrote, or code you have reviewed and understand.

Treat what you see in the Network tab as sensitive

Captured requests routinely contain session cookies, access tokens and API keys. Anyone holding those may be able to impersonate you without your password, and multi-factor authentication will not stop them. Be careful where you save that information locally to your computer. Remove them before pasting request details into a ticket, a chat, an email or an AI tool, and be careful about screen sharing with developer tools open.

Confirm what is permitted before you build on it

An endpoint responding does not mean you are licensed to use it. Vendors restrict API access to certain subscription tiers, impose rate limits, and sometimes prohibit use of undocumented internal endpoints in their terms of service. Automated traffic can also trip security controls and lock an account. Check the terms, and check with the vendor, before anything becomes a dependency.

Using this to give an AI access to a system

There is a practical reason this skill is worth more now than it was a few years ago. AI assistants are increasingly able to operate the systems you use, not just discuss them — but only where a defined interface exists to hand them. Confirming that an interface exists, and describing it accurately, is the first step in turning a manual process into one an assistant can help run.

A sensible sequence looks like this:

1. Confirm the interface exists. Use the Network tab as above. If clicking around produces structured requests, there is something to connect to.
2. Prefer the documented route. Check for a published API, an existing connector, or a vendor-supported integration. Something the vendor commits to supporting will always beat something you discovered by observation.
3. Capture the specifics. For each action that matters, record the address, the method, and the payload shape — “Copy as fetch” gives you all three accurately. This becomes the specification you hand to whoever builds the integration.
4. Sort out access properly. Issue a dedicated service account or API key for the integration, scoped to the least permission that does the job. Never let an assistant borrow a person’s own session or credentials.
5. Start read-only. Let it retrieve and summarize before it is ever allowed to create, change or delete. Most of the value usually arrives in that first read-only phase anyway.
6. Put a person on the write path. Anything that changes data, spends money, or contacts a customer should be reviewed and approved before it executes.
7. Make it observable. Log what the integration does, and make sure a human is told when it fails. A quiet, broken automation is worse than no automation.

Even more qualifiers: an undocumented internal API can be made to work, but it is a maintenance commitment — a vendor update can break it without notice, so it suits low-risk assistive work far better than anything business-critical. Vendor terms may restrict this kind of access regardless of whether it is technically possible. Data protection obligations still apply in full: sending records to an AI service is a disclosure, and it needs the same scrutiny as any other. And not everything that can be automated should be — if a task runs twice a year, the integration will cost more than it saves.

Handled with those guardrails, though, this is genuinely how a lot of useful automation begins: someone notices the system is already talking, and asks what else it could be saying.

Talk to us

If you have a repetitive task, a system that will not talk to another system, or a process that depends on someone rekeying data between two applications, it is worth a conversation with GreenLoop. The capability is often already sitting behind the interface — the work is in connecting it safely, with the right permissions and the right monitoring around it.