Your Shipping Portal Has No API. You Just Built One.

You do not need their API. You need to use their website once.

It is 9 p.m. in Lagos, and Amaka is still on her phone.

She runs a six-person homeware boutique, cushions, lamps, small furniture, shipped across Nigeria through a courier partner's web portal. The portal has a tracking page. It does not have an API. So every evening, after the shop closes, Amaka logs in, checks which of today's forty-odd orders have moved, and types "your order has shipped" into WhatsApp, one customer at a time.

She has asked the courier for API access twice. Both times: a support ticket, a promise, silence.

That is the story of most small business software. Not just couriers. Booking portals, supplier ordering systems, old point-of-sale dashboards, government and utility sites, the accounting tool your bookkeeper swears by from 2014. None of them were built with an API. Most of them never will be. You are not getting write access to their backend. You were never going to.

How do you get an API for a website that does not have one?

You do the task once, and you let an AI agent watch how the site actually works while you do it.

On August 12, 2026, Teknium, cofounder and lead engineer of Hermes Agent at Nous Research, posted this: "Have Hermes do an operation or set of operations on a website, and it can watch the api calls made there, then can create a static api for your agent or scripts it builds to use forevermore with this new optional skill." One command installs it. You demonstrate the task. Hermes watches the network traffic your browser already makes, the same requests the website's own front end sends to get your data, and turns that pattern into a small, reusable API.

Not a script that clicks buttons and breaks the moment a button moves. Not a screenshot-reading loop that guesses at pixels. A real, callable interface built from the actual requests the site was already making, quietly, the entire time you used it.

Screen-recording automation and API-capture automation are not the same thing

Notma has covered "show the AI once" tools before, Claude Cowork's screen recording among them. This is a different mechanism, and the difference matters for anyone who has ever had a script quietly stop working:

Click-replay watches your hands. Network-call capture watches the conversation your browser is already having with the server, the one that was there all along, underneath every button you have ever clicked on that site.

Why this is landing now, not a year ago

Two things had to be true first. Agents had to be trustworthy enough to leave alone with your login. And they had to be good enough at reasoning over raw network traffic, headers, tokens, pagination, to turn a messy capture into something clean enough to call twice. Both arrived this year, quietly, the same way most real shifts do.

You can see the same pattern one skill over. A YouTube tutorial from Derek Cheung, 118,798 views and counting, shows Hermes Agent's /learn and /goal commands doing the same trick in a different domain: point Hermes at a research API's documentation once, and it writes itself a permanent skill. Then hand it a CRM export with five blank company records and one instruction, and it enriches all five, unattended, citing its sources as it goes. Feed it a second CRM export from an unrelated industry, health care instead of software, and it does not need to be retaught. The skill does not care what industry the rows belong to. It already knows the drill.

That is the pattern underneath both stories. Teach the agent something once, an API, a workflow, a website you have no formal access to, and it becomes a permanent capability instead of a one-off favor you have to ask for again next Tuesday.

"Isn't this just fragile scraping with extra steps?"

Fair question, and worth answering straight rather than waving away.

Scraping reads the rendered page and guesses at what matters, brittle by design, breaking on every visual redesign. This is different because it is not reading the page at all. It is capturing the actual request and response your browser already sends and receives, the same JSON the vendor's own app depends on. That contract changes far less often than a website's layout does, because if it broke, the vendor's own site would break too.

It is not indestructible. If the courier rebuilds their backend from scratch, the captured API call stops working and you re-run the demonstration once, the same five minutes it took the first time. Compare that to a support ticket that goes unanswered for a year. The trade is not close.

Building it: turn Amaka's shipping portal into a standing API

Here is what the actual build looks like, start to finish, for a business owner who has never written a line of code.

1. Install the skill. One command in Hermes Agent's terminal or messaging gateway, hermes skills install followed by the skill's link, and the capability is loaded. No separate developer environment.
2. Log in once, with the agent watching. Amaka opens the courier's portal in a session Hermes can observe and does exactly what she does every night: checks today's shipment statuses. That is the whole demonstration.
3. Hermes captures the calls. Behind the screen, it records the requests the portal's own front end made, the endpoints, the headers, the shape of the response, the pagination if there is any.
4. It builds the static API. Hermes turns that capture into a small, named interface, "get today's shipment statuses", that any script or agent can call directly, without opening a browser at all.
5. Wire it to the actual job. Amaka points a second, simple automation at that new API: pull the day's statuses every evening, match them to WhatsApp numbers already in her order sheet, and send the "shipped" message automatically, one line each, sources intact.
6. Spot-check before you trust it fully. Run it for a week alongside your own manual check. Confirm the matches are right. Then let it run on its own.

Forty messages a night, typed by hand, become zero. Amaka's evening is hers again. The courier never had to answer a single support ticket.

The same six steps work for a supplier ordering portal with no API (build a standing "check stock levels" call instead of logging in every morning), a booking platform with no API (build "get today's appointments" and drive your own reminder texts), or an old accounting dashboard your bookkeeper still swears by (build "pull this month's outstanding invoices" and stop asking her to export a CSV by hand). The workflow does not change. Only the site does.

What you have after this

A week in, you have one working API for one task you used to do by hand, and the evenings back that it used to cost you.

A month in, you have three or four of them, shipment status, stock levels, today's bookings, this month's invoices, quietly running underneath whatever front-facing tool you actually use to talk to customers.

Six months in, the honest answer to "does that software have an API?" stops being a wall and starts being a Tuesday afternoon.

Same courier. Same clunky portal. Same forty orders a night. A completely different evening.