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 HTTP request execution, security, parsing, and failure behavior:

1. Execution & Timeout Settings​

  • Request Timeout: Maximum duration (in ms) the platform waits for a server response before timing out.
  • Script Timeout: Maximum duration (in ms) allowed for pre-request and test assertion scripts.
  • Number of Retries: Number of times to automatically retry failed network requests.
  • Maximum Response Size: Maximum allowed response body size in bytes (Default: 1MB / 1,048,576 bytes).

2. Failure & Abort Controls​

  • Abort on Error (abortOnError): When enabled (true), execution stops immediately if a JavaScript runtime error, script timeout, or network exception occurs, marking the test result as ABORTED.
  • Abort on Failure (abortOnFailure): When enabled (true), execution stops immediately upon the first Chai/expect assertion failure to prevent cascading test failures.

3. SSL / TLS & Protocol Settings​

  • Enable SSL Certificate Verification (strictSSL): Determines whether SSL certificates are strictly verified.
  • Extended Root CA (extendedRootCA): File path to custom enterprise Root CA certificate bundle for internal HTTPS endpoints.
  • Protocol Version (protocolVersion): Preferred HTTP protocol version (HTTP/1.0, HTTP/1.1, or HTTP/2.0).
  • Insecure HTTP Parser (insecureHTTPParser): Enables lenient HTTP header parsing for servers that send non-standard HTTP headers.
  • WhatWG URL Parser (useWhatWGUrlParser): Uses modern standard WhatWG URL parser.

4. Redirect & Header Controls​

  • Automatically Follow Redirects (followRedirects): Controls whether 3xx HTTP redirects are automatically followed.
  • Maximum Redirects (maxRedirects): Upper limit on the number of sequential redirects to follow (Default: 10).
  • Follow Original HTTP Method (followOriginalHttpMethod): Preserves the original HTTP verb (e.g. POST) when following redirects.
  • Remove Referrer Header on Redirect (removeRefererHeaderOnRedirect): Strips the Referer header across redirects.
  • Implicit Cache Control: Automatically adds Cache-Control: no-cache header.
  • Implicit Trace Header: Automatically includes unique request tracking trace IDs (PostQode-Token).
  • System Headers (systemHeaders): Injects custom global headers into all outgoing requests.
Is this documentation incorrect or incomplete? Report an issue on GitHub