About API Connection test step
The API Connection test step is used for working with asynchronous APIs. In their case, publishers send messages (or events) to a channel on a broker, and subscribers get those messages (events) by subscribing to the channel.
In ReadyAPI, the API Connection test step can operate in two modes:
-
In Publish mode, it acts as an event publisher (or producer): it connects to a broker, sends an event, and then disconnects.
-
In Subscribe mode, it acts as an event subscriber (or consumer): it connects to a broker and continues consuming events as long as the connection is open.
Currently, the API Connection test step supports only the Kafka asynchronous API. For more information on its support, see Kafka Testing.
To use the API Connection test step, you need to add a Kafka service to your project.
Editing API Connection test step
Each API Connection test step is based on a request defined in your API. ReadyAPI takes the protocol, operation, channel, and endpoint specified for this request. You can link your test step to another operation of the same type to change the channel. You can change the endpoint in the test step editor.
Here is a brief description of the API Connection test step editor:
Toolbar items
Item | Description | ||
---|---|---|---|
Protocol |
The AsyncAPI protocol that will be used for the test step (currently, only Kafka is available). |
||
Endpoint |
The endpoint of the broker.
|
||
Authorization Profile |
The authorization profile that will be used to authenticate to the broker. To learn more, see Authentication in Kafka. |
||
Operation |
The mode in which the test step will operate: Publish or Subscribe. |
||
Channel |
The channel to which the test step will connect.
|
||
Link API |
Allows linking the test step to another operation, thus changing the channel. |
||
Connection Settings |
Opens the connection settings. |
Operation modes
To learn specifics of using the API Connection test step for sending and receiving messages, see the following topics:
Simulating Producers (Publish mode)
Simulating Consumers (Subscribe mode)
Validating messages
To check incoming messages (that is, events that the test step consumes from a topic), you use assertions:
![]() |
Assertions are only available in the Subscribe mode. |
Tip: To create complex verification conditions, you can organize assertions into assertion groups.This is particularly useful for the API Connection test step because one test step receives multiple messages. For example, you can add two JSONPath Match assertions to an assertion group and configure it so that the test step passes if either of those assertions passes.
Filter assertions
You can filter the messages to show only those that either passed or failed a certain assertion. To do that, point to an assertion and select the needed option from the drop-down list.
![]() |
You can set a filter only for one assertion at a time. |

To delete the filter, click Clear:
Available assertions
Assertion | Description |
---|---|
Property Content |
|
Contains | Verifies that the incoming message contains the specified string. |
Equals | Verifies that some value in the incoming message is equal to the specified value. |
JSONPath Count | Counts the occurrences of the specified JSON item. |
JSONPath Existence Match | Checks whether the specified JSON item is present in the incoming message. |
JSONPath Match | Checks whether the specified item in the incoming message matches an expected value. |
JSONPath RegEx Match | Checks whether the specified item matches a regular expression. |
Not Contains | Verifies that the incoming message does not contain the specified value. |
Script |
|
Script Assertion | Executes a script to perform custom validation. |
Logging
While the test step editor is open, brief information on sent messages is listed in the Log tab. If the test step is run as part of a test case, you can see a more detailed log in the Transaction Log panel.