Robot Framework takes a different stance from code-first tools. Instead of writing tests as program code, you write them as tables of human-readable keywords. A test reads almost like a checklist, which means QA analysts and engineers can author and review the same suite. For API testing, the RequestsLibrary turns HTTP calls into those same readable keywords.
This guide shows how to automate API tests with Robot Framework end to end. You will install the framework and the libraries it needs, write your first keyword-driven test, manage sessions across requests, assert on status codes and JSON bodies, and build reusable keywords so the suite scales. Every example is the keyword-table syntax Robot Framework actually uses.
What Robot Framework is and why it fits API testing
Robot Framework is an open-source, generic automation framework for test automation and robotic process automation. Its defining feature is the keyword-driven syntax: tests are written in plain tables, and complex behavior is built up from libraries of keywords implemented in Python or Java.
For API testing this has two real advantages. First, the tests are readable by people who do not code, so a tester or product owner can follow what a suite verifies. Second, the framework is extensible: the RequestsLibrary wraps the Python requests library and exposes HTTP operations as keywords, while other libraries cover JSON, databases, and more. If keyword-driven structure is new to you, our broader automation testing framework guide explains where it sits among the other framework types.
Installing Robot Framework and its libraries
Robot Framework and its libraries install through pip. Work inside a virtual environment to keep the project clean:
python -m venv .venv
source .venv/bin/activate
pip install robotframework
pip install robotframework-requests
pip install robotframework-jsonlibrary
The three packages cover most API testing needs:
robotframeworkis the core engine and test runner.robotframework-requests(the RequestsLibrary) sends HTTP requests as keywords.robotframework-jsonlibraryextracts and verifies values inside JSON responses.
Confirm the install with robot --version. The official Robot Framework user guide is the reference for syntax questions as your suite grows.
One detail trips up newcomers: Robot Framework is whitespace-sensitive. Keywords and their arguments are separated by at least two spaces, not one. A single space is treated as part of the same token. Most editors with a Robot Framework plugin handle this for you, but if a test fails to parse, mis-spaced arguments are the first thing to check.
Writing your first API test
Robot Framework test files use the .robot extension and are divided into sections marked by *** Settings ***, *** Variables ***, and *** Test Cases ***. Here is a complete file that checks a users endpoint:
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Get User Returns 200
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
Status Should Be 200 ${response}
Get User Returns Expected Email
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
${body}= Set Variable ${response.json()}
Should Be Equal As Integers ${body}[id] 42
Should Be Equal ${body}[status] active
The *** Settings *** section imports libraries. Create Session opens a named HTTP session. GET On Session sends the request and returns a response object. Status Should Be and Should Be Equal are assertion keywords. Run the suite with robot tests.robot, and Robot Framework generates an HTML report and log automatically.
Working with sessions
Create Session does more than store a base URL. The session holds default headers, authentication, and cookies, so every request made on it inherits that state. This matters for any API that requires a login, because you authenticate once and reuse the session.
*** Test Cases ***
Create Order With Authenticated Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "qa@example.com", "password": "test-pass"}
${token}= Set Variable ${login.json()}[token]
${headers}= Create Dictionary Authorization=Bearer ${token}
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${headers}
Status Should Be 201 ${order}
The ... syntax continues a keyword call onto the next line, which keeps long requests readable. Create Dictionary builds the headers map. Because the session persists, you could make several follow-up requests without recreating it. The RequestsLibrary keywords for sessions are documented in the RequestsLibrary reference.
Asserting on response bodies
Checking the status code is the first step. To verify the body, parse the JSON and assert on its fields. Robot Framework’s built-in keywords cover equality and containment, and the JSONLibrary adds path-based extraction:
*** Settings ***
Library RequestsLibrary
Library JSONLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Order Response Has Correct Shape
Create Session api ${BASE_URL}
${response}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
Status Should Be 201 ${response}
${body}= Set Variable ${response.json()}
Dictionary Should Contain Key ${body} total
Should Be Equal As Integers ${body}[quantity] 2
${status}= Get Value From Json ${body} $.status
Should Be Equal ${status}[0] pending
Dictionary Should Contain Key confirms a field exists. Should Be Equal As Integers compares numeric values without type-mismatch surprises. Get Value From Json uses a JSONPath expression to reach nested data. For the wider set of checks worth running on an API response, our guide to API assertions is a good companion.
Building reusable keywords
Repeating Create Session and the login flow in every test is the keyword-driven equivalent of copy-paste. Robot Framework lets you define your own keywords in a *** Keywords *** section, so common steps become single readable lines:
*** Keywords ***
Authenticate And Open Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "qa@example.com", "password": "test-pass"}
${token}= Set Variable ${login.json()}[token]
Set Suite Variable ${AUTH_HEADERS} Bearer ${token}
*** Test Cases ***
Create Order
Authenticate And Open Session
${headers}= Create Dictionary Authorization=${AUTH_HEADERS}
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2} headers=${headers}
Status Should Be 201 ${order}
Custom keywords are how a Robot Framework suite stays maintainable. When the login endpoint changes, you edit one keyword instead of every test. For larger suites, move shared keywords into a resource file and import it, the same modular discipline described in our guide to writing automated test scripts.
A resource file is a .robot file with no test cases, only *** Keywords *** and *** Variables *** sections. You import it from a test file with Resource common.robot in the settings. This keeps the login flow, base URL, and other shared pieces in one place. As the project grows, a typical layout has one resource file per API area plus a top-level one for global setup. That separation of test cases from supporting logic is the heart of keyword-driven structure, and our broader automation testing framework guide explains why it scales.
Running Robot Framework in CI
Robot Framework runs headless and returns a non-zero exit code on failure, which is exactly what a pipeline needs to fail a build. The runner also writes output.xml, log.html, and report.html after every run, so CI artifacts are available with no extra configuration.
A few flags make CI runs cleaner. Use --outputdir to send reports to a known folder, --include and --exclude with tags to run subsets, and variable files or --variable to inject environment-specific values like base URLs and credentials without editing test files:
robot --outputdir results --variable BASE_URL:https://staging.example.com/v1 tests/
Tag your tests with [Tags] so you can run a fast smoke set on every commit and the full suite nightly. Wiring this into GitHub Actions or any other pipeline follows the same pattern as our API tests in CI/CD walkthrough: install dependencies, run the command, publish the report artifacts.
When a dedicated API platform helps more
Robot Framework is a strong choice when you want readable, keyword-driven tests that mixed-skill teams can share. It is less convenient when you also need API design, mocking, and debugging in one place, or when you want schema validation against an OpenAPI spec without assembling it from libraries.
Apidog handles those needs directly. It provides a visual test builder, automatic OpenAPI schema validation, data-driven runs from CSV and JSON, environment management, and HTML reports, with a CLI runner for CI. Teams often use both: Robot Framework where keyword-driven readability matters most, and Apidog for designing, mocking, and broadly testing the APIs under test. You can download Apidog and stand up a working API test suite without writing any keyword libraries.
Frequently asked questions
Is Robot Framework only for UI testing?
No. Robot Framework is a generic automation framework. With the RequestsLibrary it handles API testing well, and other libraries cover databases, SSH, and more. Its keyword-driven design is layer-agnostic. The framework became popular for UI testing through SeleniumLibrary, but API testing is an equally common use.
What is the difference between Create Session and a plain request?
Create Session opens a named, persistent HTTP session that stores a base URL, headers, cookies, and authentication. Subsequent keywords like GET On Session reuse that state, which is essential for APIs that require login. A sessionless request would not carry cookies or auth between calls, forcing you to re-send everything each time.
Do I need to know Python to use Robot Framework?
Not to write tests. The keyword-table syntax is designed for non-programmers, and the RequestsLibrary already exposes HTTP operations as keywords. Python knowledge becomes useful only when you want to write entirely new keyword libraries. Most API testing needs are covered by existing libraries, so many teams never write Python at all.
How does Robot Framework compare to pytest for API testing?
Pytest is code-first and suits Python teams who want tests beside application code. Robot Framework is keyword-driven and suits mixed-skill teams who value readable, table-style tests. Both run in CI and produce reports. The choice comes down to who writes and maintains the suite rather than to raw capability.
Can Robot Framework validate responses against an OpenAPI schema?
Not out of the box. You can assert on individual fields with built-in keywords and JSONLibrary, and community libraries add schema checking. If automatic validation against an OpenAPI document is central to your workflow, a platform like Apidog that does it natively will save you the library assembly and upkeep.