Robot Framework is a keyword driven automation framework that reads almost like plain English. It is popular for browser testing, but it is just as capable for APIs when you add RequestsLibrary, which wraps the Python requests library in Robot keywords. The result is an API test that a non programmer can read and follow, backed by a mature engine for running suites and producing detailed reports.
How it works
A test is a list of keywords, each one a small step with a clear name. You build a payload, send a request, then assert on the status and the body using keywords from RequestsLibrary, JSONLibrary and the built in Collections library:
*** Test Cases ***
Should Return Access Token On Successful Login
${payload}= Create Dictionary email=${EMAIL} password=${PASSWORD}
${response}= POST ${BASE_URL}/users/login json=${payload}
Status Should Be OK
Dictionary Should Contain Key ${response.json()} access_token
Variables such as ${BASE_URL} and the credentials live in a variables section, so the values stay in one place. A protected suite uses a setup keyword that logs in, captures the token, and sets an Authorization: Bearer header for the invoices request. You run a suite with robot -d results tests/, which writes a rich log.html and report.html alongside the machine readable output.xml.
Benefits
The readability is the headline. Keyword driven tests are easy for manual testers, analysts and developers to read and to write, so a whole team can work in the same suite. The reports are among the best in any test tool, with a full log of every keyword and its arguments, which makes failures quick to diagnose. The library ecosystem is broad, so the same framework can test a browser, an API and more, and it has a long track record in real projects.
Downsides
The tabular, keyword driven syntax takes some getting used to, and whitespace and argument handling can trip up newcomers. For logic heavy tests the keyword style can feel verbose compared with a few lines of Python, and complex cases often end up in a custom Python keyword library anyway. It is a framework with its own conventions, so there is a learning curve before the readability pays off. For teams that value shared, readable tests, that trade is usually worth making.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-robotframework tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, the ToolShop backend used across this series. Each suite sets ${BASE_URL} in its variables section.
Three scenarios are covered, one .robot file each. A brands suite calls GET /brands and checks for an OK status with at least two entries. A login suite posts credentials to /users/login and confirms the response contains access_token. A protected invoices suite uses a login setup to obtain the token, sets the Bearer header, calls GET /invoices, and checks the returned list. A GitHub Actions workflow runs the suites and publishes the logs and report. These are the same three checks used across every tool in this series, which makes Robot Framework easy to place next to the rest.