Talend API Tester is a Chrome extension for sending HTTP requests and inspecting responses without leaving your browser. It was formerly known as Restlet Client, and many developers still keep it installed for quick checks because there is nothing to download beyond the extension itself. It handles REST APIs, supports the common HTTP methods, and can chain requests into scenarios.
This guide shows how to use Talend API Tester for real testing work. You will install it, send your first request, organize requests into projects and services, build a scenario that runs multiple requests in sequence, and add assertions so the tool checks responses for you instead of you eyeballing them. The examples use a public API so you can follow along right away.
Install the extension and send a request
Talend API Tester lives in the Chrome Web Store. Search for “Talend API Tester” and click Add to Chrome. It also runs in Chromium-based browsers like Edge and Brave. Once installed, open it from the extensions menu or pin it to the toolbar for quick access.
The interface has a sidebar on the left and a request panel on the right. Click into the request panel and you will see a method dropdown, a URL field, and tabs for headers and body.
To send a basic request, pick GET and enter a real endpoint. The JSONPlaceholder service works well for practice:
GET https://jsonplaceholder.typicode.com/users/1
Click Send. The response appears below with the status code, the response time, the headers, and the body. Talend API Tester pretty-prints JSON and XML, so a nested response is readable without extra steps.
For a POST, change the method, open the Body section, and choose a content type. Pick application/json and enter a payload:
{
"name": "Priya Nair",
"email": "priya.nair@example.com"
}
Add headers under the Headers section. For an authenticated API, add an Authorization header with your token. The tool also has built-in authentication helpers for Basic, Digest, OAuth, and Bearer schemes if you prefer not to set the header by hand.
Organize requests into projects and services
A handful of loose requests is fine for a quick poke at an API. Once you have many, you want structure. Talend API Tester organizes work into projects, and inside a project into services.
Create a project from the sidebar and give it a clear name like “User API.” Inside it, create services that group related endpoints, for example a “Users” service and an “Orders” service. Save each request into the right service. A service can hold a base URL, so individual requests under it only need the path, which keeps things tidy.
This structure matters for two reasons. First, it makes a large set of requests navigable, so you are not scrolling through dozens of unlabeled calls to find the one you want. Second, it is the foundation for scenarios, which we cover next, because a scenario references saved requests.
Projects also help with environment switching. Talend API Tester supports environment variables, so you can define a host variable that holds your staging URL and reference it across every request in a project with a placeholder. Define a second environment with the production host, switch between them, and the whole project retargets at once. This keeps you from editing URLs by hand and from accidentally firing a destructive request at the wrong server.
Talend API Tester can also import existing work. It accepts Postman collections, Swagger and OpenAPI definitions, and HAR files. If you already have an API spec or a Postman export, import it instead of recreating every request by hand. For a structured way to think about grouping checks, the API test case example guide is a useful companion.
Build a scenario to run requests in sequence
A single request answers one question. Real testing usually means a flow: create a record, read it back, update it, delete it. Talend API Tester handles this with scenarios.
A scenario is an ordered list of saved requests. Create one from the sidebar, then add requests to it in the order they should run. When you run the scenario, the tool fires each request top to bottom and shows the result of each step.
The useful part is passing data between steps. A scenario can capture a value from one response and feed it into a later request. For example, a “create user” request returns a new id in its response body. You extract that id into a variable, then a later “get user” request uses the variable in its URL. This is how you test stateful flows rather than isolated calls.
Scenarios also support conditional logic and repetition. You can branch based on a response, so a step only runs if a previous one returned a particular status, and you can loop a step to hit an endpoint repeatedly. Combined with variable extraction, this lets a single scenario model a realistic sequence: authenticate, create a record, confirm it reads back correctly, modify it, then clean up by deleting it. Running that scenario end to end is a far better signal than firing each request in isolation. The article on test scenario versus test case explains the distinction between a single check and a multi-step flow, which maps directly onto requests versus scenarios here.
Add assertions so the tool checks responses
Running a scenario shows you what came back. Assertions make the tool decide whether what came back is correct, so you are not reading every response by hand.
Talend API Tester lets you attach assertions to a request. Open a saved request and find the assertions section. You build assertions through a form rather than by writing code. Common ones include:
- Status code equals an expected value, such as
200or201. - Response time is below a threshold, such as
500milliseconds. - A payload field matches an expected value, using a path into the JSON body.
- A header is present or has a specific value.
Each assertion you add gets evaluated when the request runs, either on its own or as a step in a scenario. The result panel marks each assertion passed or failed. Run the whole scenario and you get a clear pass or fail across every step, which turns the scenario into a repeatable regression check.
Because the assertions are form-based rather than code, the tool is approachable for testers who do not write JavaScript. That is a real strength for quick, manual verification. The flip side is that the assertion vocabulary is narrower than a scripting-based tool. If you need to assert on something the form does not express, such as a computed value or a complex condition across multiple fields, you will hit the ceiling. For most everyday checks, status code plus a couple of body-field assertions is enough. For guidance on what is worth asserting, see the deeper guide on API assertions.
Read the response correctly
Whether or not you add assertions, you should know how to read a response. Four parts matter.
- Status code. This is the first signal.
2xxmeans success,4xxmeans the request was wrong,5xxmeans the server failed. A reference like the guide on HTTP status codes REST APIs should use helps you interpret the less obvious ones. - Response time. Talend API Tester reports how long the request took. A slow endpoint is a problem even when it returns the right data.
- Headers. Headers carry
Content-Type, caching directives, rate-limit information, and CORS details. They often explain behavior the body does not. - Body. The actual data, usually JSON or XML. Check that the fields, types, and values are what the contract promises.
Reading all four together tells you whether the API is healthy, not just whether it responded.
When a Chrome extension is not enough
Talend API Tester is convenient and fast for browser-based checks. Its limits show up as work grows. It is tied to Chrome, so it cannot run headless in a CI pipeline. Its assertion system is solid but basic compared to a full testing platform. And it does not cover API design, mocking, or documentation, so it is one tool among several rather than a single workspace.
Apidog is an all-in-one API platform that fills those gaps. It is a standalone application rather than a browser extension, it imports Postman, OpenAPI, and other formats just like Talend API Tester does, and it adds a visual assertion builder, mock servers, automated test scenarios, and generated documentation in one project. Because the spec and the tests share one source of truth, they do not drift apart. You can download Apidog and import your existing requests to compare. For a wider survey of options, the comparison of online API testing tools that are free is a good starting point.
Talend API Tester remains a fine choice for fast, in-browser checks. Match the tool to the size and stage of your testing work.
Frequently asked questions
Is Talend API Tester the same as Restlet Client?
Yes. Talend API Tester is the renamed version of the tool that used to be called Restlet Client. The functionality is the same lineage: a Chrome extension for sending HTTP requests, organizing them, and running scenarios with assertions.
Is Talend API Tester free?
There is a free version available in the Chrome Web Store that covers sending requests, organizing them into projects, and building scenarios with assertions. Paid tiers historically added team features and larger limits. The free version is enough for most individual testing work.
Can Talend API Tester run tests in CI/CD?
Not directly. It is a Chrome extension and runs inside the browser, so it cannot execute headless in a pipeline. For automated tests that run on every commit, you need a tool with a command line runner. The guide on automating API tests in CI/CD covers what that setup looks like.
What formats can Talend API Tester import?
It can import Postman collections, Swagger and OpenAPI definitions, and HAR files. This lets you bring in existing API specs or exports instead of recreating every request manually.
How is a scenario different from a single request?
A single request sends one HTTP call and shows one response. A scenario is an ordered list of requests that run in sequence, and it can pass data captured from one response into a later request. Scenarios test multi-step flows, like create then read then delete, while a single request tests one isolated call.