Pre/Post Processors in Apidog

Pre and Post-request Processors are a key feature in Apidog. When you send a request, you can use pre-request processors to dynamically control your request, or use post-request processors to handle the received response.

In Postman, all pre and post-request operations need to be implemented using scripts, which is more complex, less maintainable, and has a higher learning curve. In contrast, Apidog allows you to conveniently perform the majority of pre and post-request operations through visual, drag-and-drop actions.

Getting started with pre/post processors

Here are the steps to use pre and post-request processors in Apidog:

Open any endpoint and navigate to the Run tab (Design-first Mode) or Request tab (Request-first mode).

Design-first Mode

Request-first Mode

Switch to the Pre processors or Post processors section, hover over Add processor, and select the desired processor to add.

Fill in the necessary fields for the added processor.

Click Send, and the request will execute with the configured pre/post processors.

In Design-first Mode, click Save as case to save the request. In Request-first Mode, click Save/Save as case to save the request.

Design-first Mode

Request-first Mode

In Apidog, you can also create a standalone request and apply pre and post-processors to it. However, the recommended approach is to leverage the pre and post-processors on top of the endpoint specification. This makes the API debugging and testing process more convenient and streamlined.

What do pre/post processors do

Pre/post processors can collectively achieve various functionalities like below.

Pre processors

Setting the values of request parameters and the request body: This involves defining the input data that will be sent to the API endpoint for processing.

Setting request headers: Specifying necessary headers such as Content-Type, Accept, Authorization, etc., for the API request.

Adding authentication to the request: Including authentication tokens, API keys, or any other credentials required for accessing protected endpoints.

Retrieving values from a database to use as request parameters: Fetching relevant data from a database to populate the API request with dynamic or pre-defined values.

Encrypting the request: Securing the data being transmitted by encrypting the request payload to protect sensitive information.

Post processors

Writing assertions to validate the response received from the API against expected results. This can include checking status codes, response messages, specific data values, etc.

Extracting variables from the response to use them in subsequent requests. This is useful for maintaining state and continuity in API test flows.

Writing data to a database to store or update information generated during API testing. This can be particularly useful for scenarios where data persistence is required for later analysis or reference.

Visualizing response data for better analysis and understanding. This can involve generating reports, graphs, or any other visual representation of the API response data to gain insights into the system's behavior and performance.

List of pre/post-request processors

Apidog supports the following pre/post processors:

Assertion: Available only in post processors. Allows you to define validation rules to check the response data against expected values or conditions. It supports various assertion types like status code, response body, headers, etc.

Extract variable: Available only in post processors. Enables extracting values from the response (JSON, XML, or plain text) and storing them as variables. It supports using JSONPath and XPath expressions to target specific parts of the response. Variables can be used in subsequent requests or other processors.

Database Operation: Available both in pre and post processors. Allows you to connect to databases and execute SQL queries. The query results can be stored as variables for use in further processing. It supports various database types, including SQL and NoSQL databases.

Custom Scripts: Available both in pre and post processors. Provides a scripting environment where you can write your own JavaScript code. Scripts can access request and response data, as well as environment variables. It's useful for complex logic or integrations that cannot be easily expressed through the visual processors.

We recommend using the Apidog Script Generator to simplify script writing. Simply describe the script you want in natural language, and the generator will create a runnable script for you.

Public Scripts: Available both in pre and post processors. Enables creating reusable script snippets that can be shared across multiple processors or scenarios. It's helpful for encapsulating common logic or utility functions.

Wait: Available both in pre and post processors. Introduces a delay or wait period before or after a request is sent. It's useful for simulating real-world scenarios or handling asynchronous responses.

The execution order of pre/post processors

The pre and post-request processors in Apidog can be set at multiple levels:

Run/Endpoint case level: Default level. Processors set at this level will only affect the current run/endpoint case.

Endpoint level: Processors set at the endpoint level will be applied to all cases (requests) associated with that endpoint.

Folder level: Processors configured at the folder level will impact all endpoints within that folder.

A set of pre-operations in a request may look like this:

In the screenshot above, the first three processors are grouped under the label "Inherit from parent". The label on the right-hand side indicates that they are located in the Root folder, Pets folder, and the current endpoint. In the current run, these processors can only be executed or switched on/off, but not edited directly. If you need to edit them, you can click the folder to navigate to the corresponding level.

The "Inherit from parent" processors are collapsed by default, and you can click the checkbox in front of them to choose whether to execute them or not.

The last processor, a custom script, is a new addition in the current run and can be edited within the current run.

Variable Substitution

You may also notice that at the end of all the pre-processors, there is a step called "Variable Substitution & Inherit from Parents".

In Apidog, the "Variable Substitution" pre-processor is a special pre-processor that serves the purpose of replacing variable placeholders like {{variable}} with their current values.

Most pre-processors can be executed before variable substitution, which is the default execution order in Apidog. However, some processors require execution after variable substitution to be effective, such as scripts like API signature. In such cases, these processors need to be manually moved after the "Variable Substitution & Inherit from Parents" step.

Additionally, in the parent pre-processor section, you can also drag a processor after the variable substitution. These parent-level operations will then appear in the "Inherit from Parents" section within the "Variable Substitution & Inherit from Parents" step.

Execution order

The processors execution order for a single request looks like this:

Pre/Post Processors in Apidog

Getting started with pre/post processors#

What do pre/post processors do#

Pre processors#

Post processors#

List of pre/post-request processors#

The execution order of pre/post processors#

Variable Substitution#

Execution order#