API automation
What is API automation?
API automation makes systems work together through their APIs instead of their screens. A flow or a service sends a request and processes the structured response, with no one clicking through a user interface.
An API contract describes the endpoints, the operations, the fields, the authentication, and the error codes. REST APIs commonly use HTTP and JSON; other styles and protocols exist too. The automation can pull data on a schedule, react to a webhook, or carry out a business action such as creating an order.
This is the sturdier alternative to screen scraping. Because it talks to a supported contract rather than a layout, it does not break every time a button moves or a page is redesigned.
A worked example: creating orders
A webshop sends an event when an order is paid. An integration service validates the payload and posts it to the ERP API.
The request carries an idempotency key based on the webshop order number. If a network error triggers a retry, the server can recognise the same order instead of creating a duplicate. On success, the integration stores the ERP order number. A functional rejection, such as an unknown product code, goes to a business exception queue rather than being retried forever.
Authentication and authorisation
APIs authenticate with OAuth 2.0, a client certificate, or an API key, among others. For unattended work, use a service identity and grant only the scopes or roles it actually needs. Keep secrets in a secret store, rotate them, and make sure headers and credentials never end up in your logs. TLS protects the transport, but it does nothing about an identity that holds too many permissions.
Check two things separately: who is allowed to call the API, and which specific records or actions that caller may touch.
Idempotence and retries
Reads are usually safe to repeat. Creating or paying for something is not. Design a unique business key or an idempotency key so a repeat call is recognised. Retry temporary failures such as timeouts, throttling, and certain server errors with a bounded exponential backoff and some jitter. Do not retry a validation error as if it will fix itself.
An unknown outcome calls for a status check. After a dropped connection, the server may already have done the work, and blindly resending can double it.
Pagination, rate limits and versions
Many list endpoints return pages. The client has to follow the next links, cursors, or page numbers correctly and stop when the source is done. Filter at the source and ask only for the fields you need, since pulling a whole table to find one record wastes everyone's capacity. Respect the rate limit and the concurrency ceiling, and treat a large one-off backfill differently from daily incremental work.
APIs also change. They add fields, announce deprecations, and introduce new versions. Let your client tolerate unknown extra fields where the contract allows it, lean on schema and contract tests, and assign an owner to handle upgrades before an old version is switched off.
API automation versus screen scraping
API automation uses a supported machine contract and needs no interactive desktop, so it tends to be faster, scales further, and survives layout changes. Screen scraping and UI-driven RPA operate the human interface instead, which lets them reach functions that have no API at all, at the cost of a session, fragile selectors, and more maintenance.
Use the API when it covers the need. Reach for UI automation for legacy systems and desktop tasks with no other way in. Calling an undocumented internal endpoint is not the same as a supported integration, because it can vanish without notice.
What to watch out for with API automation
A 200 is not always success. An HTTP 200 can still wrap a functionally wrong response. Check the business result, not only the status code.
Log for tracing, not for leaking. Record a correlation id, the endpoint, the status code, the duration, and the business key, without keeping sensitive payloads you do not need.
Treat it as a live coupling. API automation connects two systems that can each affect the other. Write down the contract, the owner, the service level, and the recovery procedure.
Prefer supported connectors. A custom connector or an iPaaS platform gives you a maintained, documented path. A scraped or undocumented one is a liability waiting to break.