Skip to main content

Request Elements in PostQode

To pass the data into an API Request in PostQode, refer to the sections below:

Parameters​

Request parameters are used to send additional information to the server. While these parameters are typically included in the URL, PostQode offers a separate action to conveniently add and manage them.

Authorization​

APIs use authorization to ensure that the request is sent by an authorized user.

PostQode supports four types of authorization that are given below:

No Auth​

This is suitable for APIs that are public or when authorization is not required.

Bearer Token​

This allows a request to authenticate using an access key, such as a JSON Web Token.

Basic Auth​

This is used by an HTTP user agent (e.g., a web browser) to provide a username and password while making a request.

Digest Auth​

Similar to Basic Auth, but does not require a password to be transmitted.

Headers​

Request headers provide crucial context to the server about the request being created. In PostQode, you can customize headers to include any specific information relevant to your API interaction. The commonly used headers are given below:

  • Content-Type: Specifies the format of the data in the request body (e.g., application/json, application/xml).
  • Accept: Specifies the expected data format for the response from the server.
  • Authorization: Includes authentication credentials for secured requests (for example, Bearer token, Basic authentication).

Preset Headers​

Preset headers in HTTP requests refer to commonly used headers that provide essential information about the request or client to the server. These headers are standardized and serve various purposes, including authentication, content negotiation, and caching. The commonly used preset headers are given below:

  • Authorization: Provides credentials for authentication, such as a Bearer token or Basic authentication credentials.

  • Content-Type: Specifies the format of request body data, such as application/json, application/xml, or multipart/form-data.

  • Accept: Indicates the expected format of the response from the server, which helps negotiate content.

  • User-Agent: Identifies the client that creates the request, typically including information about the software (browser or API client) and its version.

  • Cache-Control: Directives for caching mechanisms in both requests and responses to control caching behavior.

  • Cookie: Includes cookies associated with the request, allowing for session management and stateful interactions.

  • If-Modified-Since: Allows conditional requests based on the last-modified timestamp of a resource, reducing bandwidth usage.

These headers are integral to how HTTP works and are managed by both clients (such as browsers or API clients) and servers to ensure effective communication and functionality. When using tools like PostQode or making HTTP requests programmatically, understanding and utilizing these headers correctly can significantly impact the reliability and security of your interactions with web services.

Body​

When sending an API request, data can be added either in the request body or in the parameters depending on the request method. If the request method requires a request body, then you can add data to the body of an API request.

PostQode supports five types of request bodies as given below:

None​

This type of request does not contain a body.

Raw​

This type of body is used to send data in bulk or as a string and supports various types of raw data. The request body accepts data in the formats given below:

  • JSON
  • HTML
  • XML
  • JavaScript
  • Text
  • GraphQL

Binary​

This type of body is used to send files, videos, images, or audio files along with the request.

Form Data​

This type of body is used to send data in the form of key-value pairs. You can add data by entering it in the fields (Key, Value Type, and Value) provided or by linking the value to a dataset.

X-WWW-FORM-URLENCODED​

This type of body describes form data that is sent in a single block in the HTTP message body.

GraphQL​

GraphQL is a query language and runtime for APIs that allows clients to request exactly the data they need. In PostQode, you can send GraphQL queries, mutations, and subscriptions using the Raw body type with GraphQL format selected.

GraphQL Query Structure​

A typical GraphQL request contains:

  • Query/Mutation/Subscription: The operation type and the fields you want to retrieve or modify
  • Variables: Optional parameters that can be passed to make queries dynamic

Pre-Request​

This section allows you to execute a set of commands before sending the request. These commands can include tasks like setting up variables or generating random values for use in the request. Click the 'Help' icon (?) to access pre-request script examples and sample codes.

Tests​

This section allows you to write test scripts that run after the request is sent. These scripts can validate the response, extract data, and perform assertions. Click the 'Help' icon (?) to access test script examples, assertion samples, and code snippets.

Script​

A script typically refers to a piece of code that you can use to dynamically generate or manipulate request parameters before sending a request to a server. The script can be written in a scripting language, such as JavaScript.

Request Settings​

PostQode's Request Settings feature lets you customize the platform to your preferences. Adjust various parameters to optimize its behavior, functionality, and performance.

A set of more specific settings and their descriptions are given below:

  • Request Timeout: The maximum duration the platform waits for a response from the server before considering the request timed out.
  • Script Timeout: The maximum duration allowed for the execution of scripts or test scenarios.
  • Maximum Response Size : Maximum size of the response in bytes.
  • On Error: Defines the action to be taken when an error occurs during test execution, such as logging the error, retrying the request, or aborting the test.
  • On Failure: Specifies the action to be taken when a test case fails, such as sending notifications, logging the failure, or executing customized error-handling logic.
  • Enabling SSL Certification Verification: Determines whether the platform verifies SSL certificates while making HTTPS requests.
  • Automatically follow redirects: Determines whether the platform automatically follows redirects received from the server during a request.
  • Follow original HTTP method: Indicates the HTTP method (GET, POST, PUT, etc.) for subsequent redirects.
  • Removing referrer header on redirect: Controls whether the platform removes the referrer header from the request while following redirects.
  • Encoding URL automatically: Controls whether the platform automatically encodes URLs in requests to comply with URL encoding standards.
  • Implicit Cache Control: Implicit Cache Control in PostQode refers to how PostQode automatically handles caching behavior (especially of GET requests) even when you don’t explicitly set cache-related headers like Cache-Control, Expires, or ETag.
  • Implicit Trace Header: In PostQode, an Implicit Trace Header refers to automatically added headers—most notably PostQode-Token—that PostQode includes in requests without user input. These headers help uniquely identify and trace each request, prevent cached responses from being reused, and assist in debugging or tracking request flow, especially when multiple similar requests are sent.
  • Insecure HTTP Parser : Insecure HTTP Parser is a Node.js (and PostQode) setting that allows the HTTP parser to accept malformed or non-standard HTTP headers or requests that would normally be rejected for security reasons.
  • Number of retries: Specifies how many times the platform should retry a request in case of failure before considering the request failed.
Is this documentation incorrect or incomplete? Report an issue on GitHub