How to Configure API Requests in E2E Test Automation

This guide walks you through every step required to configure and execute API requests in E2E Test Automation. Whether you’re new to API testing or just getting started with the platform, this documentation is designed to help you understand each element clearly and confidently.

Request Configuration

1. Enter the API URL

Every API call starts with the endpoint URL—this is the web address where your API lives, similar to how a website has an address.

Steps:

1. Open or create a new API request under a collection
2. Locate the URL input field at the top of the request editor
3. Paste or type your full endpoint URL

Example:

https://api.example.com/users

What This Does:

• The URL tells E2E Test Automation exactly where to send your request
• It specifies the server address and the specific resource or endpoint you want to access
• Think of it as the destination address for your API call

Tips:

• Always use the complete URL including the protocol (https:// or http://)
• Make sure there are no extra spaces before or after the URL
• Use environment variables for base URLs to easily switch between environments (dev, staging, production)

2. Add Parameters (Params)

Query parameters allow you to pass filters, configuration values, or additional data through the URL itself. They appear after a ? in the URL and help you refine what data you want from the API.

What Are Query Parameters?

Query parameters are key-value pairs added to the end of a URL. For example:

https://api.example.com/users?role=admin&status=active

In this URL:

• role=admin is one parameter
• status=active is another parameter
• Multiple parameters are separated by &

Steps:

1. Click on the Params tab beside the URL input field
2. Add your key-value pairs:
   • Key: Name of the parameter (e.g., role, page, limit)
   • Value: The value you want to pass (e.g., admin, 2, 50)
3. E2E Test Automation automatically constructs the URL with these parameters

Common Use Cases:

• Filtering: status=active to get only active records
• Pagination: page=2&limit=20 to get the second page with 20 items
• Sorting: sort=name&order=asc to sort results alphabetically
• Searching: search=john to find records matching “john”
• Date ranges: from=2024-01-01&to=2024-12-31 to filter by date

Benefits:

• Visual interface makes it easy to add, edit, or remove parameters
• Parameters can be enabled/disabled with a checkbox without deleting them
• No need to manually format the URL—E2E Test Automation handles encoding automatically
• Great for testing different combinations quickly

3. Set Authorization

Authentication ensures your API request is secure and that the server accepts it. Different APIs use different authentication methods, and E2E Test Automation supports all the most common approaches.

Why Authorization Matters:

• Most production APIs require authentication to prevent unauthorized access
• Authorization proves your identity to the server
• Without proper authorization, you’ll typically receive 401 (Unauthorized) or 403 (Forbidden) errors

Steps:

Click on the Authorization tab to view and select from available authentication methods.

Supported Authorization Methods:

Inherit from Parent

Inherits authentication settings from the parent collection or folder, avoiding repetition across multiple requests.

When to Use:

• When multiple requests in a collection use the same authentication
• To maintain consistency across related API calls
• To simplify updates—change auth once in the parent, and all child requests inherit it

How It Works:

• Set authentication at the collection or folder level
• Individual requests automatically use those settings
• You can still override it for specific requests if needed

No Auth

Use this when the API endpoint doesn’t require any authentication.

When to Use:

• Public APIs that don’t require credentials
• Internal development endpoints without security
• Health check or status endpoints
• Testing endpoints that are intentionally open

Note: Even if an endpoint doesn’t require auth, you may still need to set headers like Content-Type.

Basic Auth

Simple username and password authentication, commonly used for basic security needs.

How It Works:

• You provide a username and password
• E2E Test Automation combines them as username:password
• Encodes the combination in Base64 format
• Sends it in the Authorization header as: Authorization: Basic <encoded-credentials>

Fields:

• Username: Your account username (e.g., admin)
• Password: Your account password (e.g., admin123!)

When to Use:

• Legacy systems or internal tools using basic authentication
• Simple APIs that don’t require complex security
• Development and testing environments

Security Note: Basic Auth sends credentials with every request, so always use HTTPS to protect them from interception.

Basic Auth (Custom)

An advanced version of Basic Auth that allows you to configure a custom login flow, typically for multi-step authentication processes.

How It Works:

• Configure a separate login request that returns authentication credentials
• Extract tokens or session information from the login response
• Use those credentials in subsequent requests

Configuration Steps:

1. Select HTTP Method: Choose the method for your login endpoint (usually POST)
2. Set Auth URL: Enter the login endpoint URL (e.g., https://api.example.com/auth/login)
3. Add Headers/Body: Include any headers and request body needed for login
4. Define Expected Response Fields: Specify which fields contain the authentication token (e.g., token, access_token, sessionId)

When to Use:

• When the API requires a login call before accessing other endpoints
• Multi-step authentication flows
• When you need to extract session tokens or cookies from a login response
• Custom authentication schemes not covered by standard methods

Example Flow:

1. Make a POST request to /auth/login with username/password
2. Extract the access_token from the response
3. Use that token in subsequent API requests

Bearer Token

Token-based authentication commonly used in modern REST APIs. The token acts as your credential for accessing protected resources.

How It Works:

• You obtain a token (usually from a login or OAuth flow)
• Paste the token into E2E Test Automation
• It’s sent in the Authorization header as: Authorization: Bearer <your-token>

Configuration Steps:

1. Select Bearer Token from the authorization dropdown
2. Paste your token into the Token input field
3. The token will be included automatically in all requests using this auth method

When to Use:

• Modern REST APIs using token-based authentication
• After obtaining a token from a login endpoint
• When working with JWT (JSON Web Token) based systems
• APIs that use OAuth 2.0 access tokens

Token Sources:

• Login API responses
• Developer portals or dashboards
• Environment variables (recommended for security)
• OAuth token endpoints

Best Practice: Store tokens in environment variables rather than hardcoding them in requests, making it easy to switch between different users or environments.

JWT Bearer (JSON Web Token)

A specialized form of Bearer Token authentication where you can generate JWTs directly within E2E Test Automation using cryptographic signing.

What is JWT?

• JWT is a secure way to transmit information between parties as a JSON object
• It’s digitally signed, so the server can verify it hasn’t been tampered with
• Contains three parts: header, payload (claims), and signature

Configuration Steps:

1. Select JWT Bearer from the authorization dropdown
2. Configure the following fields:Algorithm: The signing algorithm used to generate the tokenSecret Key: The secret key used for signing the tokenPayload (JSON): The claims or data to include in the tokenOptional Headers: Additional JWT header fields
   • Usually includes token type and algorithm, but can include custom headers
   • Example: {"userId": 123, "role": "admin", "exp": 1735689600}
   • Common claims: sub (subject), exp (expiration), iat (issued at)
   • Must match the key expected by your API server
   • Keep this secure and never expose in client-side code
   • Common options: HS256 (HMAC SHA-256), RS256 (RSA SHA-256)
3. E2E Test Automation generates the JWT and includes it in the Authorization header

When to Use:

• APIs that require self-contained, signed tokens
• Microservices architectures using JWT for authentication
• When you need to generate test tokens with specific claims
• Testing different token expiration scenarios or permissions

Security Note: The secret key should be stored securely, preferably in environment variables.

OAuth 2.0

A comprehensive authorization framework for secure, delegated access. OAuth 2.0 is the industry standard for authorization and is used by most major platforms (Google, Facebook, GitHub, etc.).

What is OAuth 2.0?

• OAuth allows applications to access resources on behalf of a user without sharing passwords
• Uses access tokens with limited lifetimes
• Supports various “grant types” for different scenarios

Configuration Steps:

1. Select OAuth 2.0 from the authorization dropdown
2. Configure the required fields:

Token Name:

• A friendly name for this token configuration
• Helps you identify different OAuth configurations
• Example: “Production API Token”, “GitHub Access Token”, or “Google Drive Integration”

Grant Type:

• The OAuth flow to use based on your application type
• Available options:
  • Authorization Code: For web applications, most secure option
  • Client Credentials: For server-to-server communication without user involvement
  • Implicit: For browser-based apps (less common now due to security concerns)
  • Password Grant: For trusted first-party apps where you own both client and server

Callback URL (Redirect URI):

• The URL where the OAuth provider sends the user after authorization
• Must match exactly what’s registered in your OAuth application settings
• Example: https://oauth.pstmn.io/v1/callback
• If this doesn’t match, the authorization will fail

Authorization URL:

• The endpoint where users are sent to log in and authorize your application
• Provided by the OAuth service’s documentation
• Example: https://accounts.google.com/o/oauth2/v2/auth (Google)
• This is where the OAuth flow begins

Access Token URL:

• The endpoint where authorization codes are exchanged for actual access tokens
• Where E2E Test Automation retrieves the access token after authorization
• Example: https://oauth2.googleapis.com/token (Google)
• Used in the background after user authorization

Client ID:

• Your application’s unique identifier
• Obtained when registering your application with the OAuth provider
• Public identifier—safe to expose in client-side code
• Example: abc123-xyz789.apps.googleusercontent.com

Client Secret:

• Your application’s secret key for authentication
• Keep this confidential and secure—never expose in client-side code
• Used to authenticate your application to the OAuth provider
• Treat it like a password

Scope:

• Defines what permissions you’re requesting from the user
• Determines what resources the access token can access
• Multiple scopes are usually space-separated
• Example: read:user write:repo (GitHub) or https://www.googleapis.com/auth/drive.readonly (Google Drive)
• Request only the minimum permissions needed for your application

State (Optional):

• A random value for security purposes
• Prevents CSRF (Cross-Site Request Forgery) attacks
• Validated when the OAuth provider redirects back to your application
• E2E Test Automation can auto-generate this value

Client Authentication Method:

• Specifies how to send client credentials to the token endpoint
• Available options:
  • Send as Basic Auth header: Most common and secure method
  • Send client credentials in body: Alternative method, sends credentials in the request body

1. Click Get New Access Token
2. E2E Test Automation opens the authorization flow in your browser
3. Log in and authorize the application
4. The access token is retrieved and stored automatically
5. Use the token in your API requests

When to Use:

• Integrating with third-party APIs (Google, GitHub, Twitter, etc.)
• Building applications that need user consent for data access
• When you need delegated authorization
• APIs that require OAuth 2.0 compliance

Common Scenarios:

• Accessing user’s Google Drive files
• Posting to user’s social media accounts
• Reading user’s email or calendar
• Any scenario where you need permission to act on behalf of a user

API Key

A simple authentication method where you send a unique key with each request. API keys are commonly used for public APIs or internal service authentication.

How It Works:

• The API provider gives you a unique key (a long string of characters)
• You include this key in every request
• The server validates the key to authorize your request

Configuration Steps:

1. Select API Key from the authorization dropdown
2. Configure the following:Key: The name of the parameter or headerValue: Your actual API keyAdd to: Where to send the API key
   • Header (Recommended): Sent in request headers, more secure
   • Query Params: Appended to the URL, easier but less secure
   • Example: abc123def456ghi789jkl012mno345
   • Obtained from the API provider’s dashboard or developer portal
   • Keep this secure and treat it like a password
   • Example: x-api-key, api_key, apikey, Authorization
   • The API documentation will specify what name to use

When to Use:

• Public APIs with usage limits (weather, maps, translation services)
• Internal microservices authentication
• Simple authentication without complex flows
• Development and testing environments

Header vs Query Parameter:

Header (Recommended):

Authorization: ApiKey abc123def456

or

x-api-key: abc123def456

Query Parameter:

https://api.example.com/data?api_key=abc123def456

Best Practices:

• Always use HTTPS when sending API keys
• Store keys in environment variables, not in code
• Rotate keys periodically for security
• Use different keys for different environments (dev, staging, production)
• Monitor API key usage to detect unauthorized access

4. Request Headers

Headers are metadata sent with the request that provide additional information to the server about the request itself, the client making the request, or the expected response format.

What Are Headers?

Headers are key-value pairs sent before the actual request body. They tell the server important information like:

• What type of data you’re sending
• What format you expect in the response
• Authentication credentials
• Client information
• Caching preferences

Common Headers:

Content-Type: Tells the server what format your request body is in

• application/json – For JSON data (most common in REST APIs)
• application/xml – For XML data
• application/x-www-form-urlencoded – For form submissions
• multipart/form-data – For file uploads
• text/plain – For plain text

Accept: Tells the server what response format you prefer

• application/json – Request JSON response
• application/xml – Request XML response
• */* – Accept any format

Authorization: Contains authentication credentials

• Bearer <token> – For token-based auth
• Basic <credentials> – For basic auth
• ApiKey <key> – For API key auth

User-Agent: Identifies the client making the request

• Example: E2E-Test-Automation/1.0
• Helps servers track usage and provide appropriate responses

Custom Headers: Any application-specific headers

• x-api-version: v2 – API version specification
• x-request-id: 12345 – Request tracking
• x-tenant-id: acme-corp – Multi-tenant identification

Configuration Steps:

1. Click the Headers tab in the request editor
2. Add required key-value pairs:
   • Key: Header name (e.g., Content-Type)
   • Value: Header value (e.g., application/json)
3. Add as many headers as needed
4. Enable/disable individual headers with checkboxes without deleting them

Auto-Generated Headers:

E2E Test Automation automatically adds some headers:

• Content-Length – Size of the request body
• Host – The server hostname
• User-Agent – E2E Test Automation identifier

You can override these if needed, but usually, the defaults work fine.

When to Add Headers:

• When the API requires specific content types
• For authentication (though often handled in the Auth tab)
• When working with versioned APIs
• For custom application requirements
• To control caching behavior
• For debugging and tracing requests

5. Request Body

The request body contains the actual data you want to send to the server. It’s primarily used with POST, PUT, and PATCH requests when creating or updating resources.

When to Use a Request Body:

• POST requests: Creating new resources (new user, new order, new post)
• PUT requests: Completely replacing existing resources
• PATCH requests: Partially updating existing resources
• GET/DELETE requests: Typically don’t use a body (data is in URL/params)

Body Format Options:

Steps:

1. Click the Body tab in the request editor
2. Choose the appropriate body format for your API

none

No request body is sent with the request.

When to Use:

• GET requests (retrieving data)
• DELETE requests (removing resources)
• HEAD requests (getting only headers)
• Any request that doesn’t need to send data

form-data (multipart/form-data)

Sends data as individual parts, commonly used for file uploads or when mixing text fields with files.

How It Works:

• Data is sent in multiple parts, each with its own content type
• Ideal for uploading files along with other form fields
• Browser forms with file inputs use this format

Configuration:

• Add key-value pairs just like query parameters
• For each key, choose the type:
  • Text: Regular text values
  • File: Upload files from your computer

When to Use:

• Uploading images, documents, or other files
• Submitting forms that include file attachments
• Sending profile pictures, document uploads, CSV imports, etc.

Example Use Case:

Key: username | Value: johndoe | Type: Text
Key: email | Value: john@example.com | Type: Text
Key: avatar | Value: [profile.jpg] | Type: File

x-www-form-urlencoded (application/x-www-form-urlencoded)

Sends data as URL-encoded key-value pairs, similar to how traditional HTML forms submit data.

How It Works:

• Data is formatted like query parameters but sent in the body
• Keys and values are URL-encoded (spaces become %20, etc.)
• Content-Type header is set to application/x-www-form-urlencoded

Configuration:

• Add key-value pairs in a table format
• E2E Test Automation handles encoding automatically

When to Use:

• Traditional form submissions (login forms, contact forms)
• APIs that expect form-encoded data
• Simple data without nested structures
• When the API documentation specifies this format

Example:

Key: username | Value: johndoe
Key: password | Value: secret123
Key: remember_me | Value: true

Sent as: username=johndoe&password=secret123&remember_me=true

raw

Allows you to manually write the request body in any format. Most flexible option.

Supported Formats:

• JSON (application/json): Most common for REST APIs
• XML (application/xml): For SOAP or legacy systems
• Text (text/plain): Plain text data
• HTML (text/html): HTML content
• JavaScript: For specific use cases
• Custom: Any other format

Configuration:

1. Select the format from the dropdown (usually JSON)
2. Write your data in the text editor
3. E2E Test Automation provides syntax highlighting for easier editing

JSON Example:

{
  "firstName": "John",
  "lastName": "Doe",
  "email": "john.doe@example.com",
  "age": 30,
  "address": {
    "street": "123 Main St",
    "city": "Springfield",
    "zipCode": "12345"
  },
  "preferences": {
    "newsletter": true,
    "notifications": ["email", "sms"]
  }
}

XML Example:

<?xml version="1.0" encoding="UTF-8"?>
<user>
  <firstName>John</firstName>
  <lastName>Doe</lastName>
  <email>john.doe@example.com</email>
  <age>30</age>
</user>

When to Use:

• REST APIs expecting JSON payloads
• SOAP services requiring XML
• Any custom data format
• When you need full control over the body content

Benefits:

• Complete flexibility over content
• Syntax highlighting helps prevent errors
• Can use environment variables within the body
• Copy-paste from documentation or other sources

binary

Allows you to send a single file as the entire request body without any encoding or wrapping.

How It Works:

• The file’s raw bytes are sent directly as the request body
• No form encoding or multipart structure
• The Content-Type header should match the file type

Configuration:

1. Select binary option
2. Click Select File to choose a file from your computer
3. The file is uploaded and its raw content sent as the body

When to Use:

• Uploading a single file without any additional data
• APIs that expect raw file content
• Image processing APIs
• Document conversion services
• Binary data uploads

Example Use Cases:

• Uploading an image directly to an image processing API
• Sending a PDF to a document parsing service
• Uploading audio/video files for transcoding
• Binary protocol communications

Content-Type Examples:

• Image: image/jpeg, image/png
• PDF: application/pdf
• Video: video/mp4
• Audio: audio/mpeg

GraphQL

Specialized format for GraphQL APIs, which use a query language for APIs instead of traditional REST endpoints.

Note: Based on your earlier clarification, if E2E Test Automation doesn’t support GraphQL, this section can be removed. However, I’m including it here in case it’s a planned feature or I misunderstood the scope.

How It Works:

• GraphQL uses a single endpoint for all operations
• You write queries or mutations in GraphQL syntax
• The server returns exactly the data you requested

Configuration:

1. Select GraphQL option
2. Write your GraphQL query or mutation in the editor
3. Add variables in the variables section if needed

When to Use:

• APIs built with GraphQL
• When you need to fetch specific fields from complex data structures
• Mobile apps that need to minimize data transfer

(Remove this section if GraphQL is not supported)

6. Set HTTP Method

Every API request must specify an HTTP method, which defines what action you want the server to perform. The method is the verb that tells the server what you’re trying to do.

Why Methods Matter:

Different HTTP methods have different meanings and behaviors:

• They indicate the type of operation (read, create, update, delete)
• Servers handle them differently
• They follow REST conventions for predictable API behavior

Supported Methods:

GET – Retrieve data from the server

Purpose: Read or fetch data without modifying anything on the server

Characteristics:

• Safe: Doesn’t change server state
• Idempotent: Calling it multiple times has the same effect as calling it once
• Cacheable: Responses can be cached for performance

When to Use:

• Fetching a list of users
• Getting details about a specific resource
• Retrieving search results
• Loading dashboard data

Examples:

GET /users – Get all users
GET /users/123 – Get user with ID 123
GET /products?category=electronics – Get filtered products

Note: GET requests typically don’t have a request body.

POST – Send new data to create resources

Purpose: Create new resources on the server

Characteristics:

• Not safe: Changes server state by creating resources
• Not idempotent: Calling it multiple times creates multiple resources
• Often returns the created resource with a new ID

When to Use:

• Creating a new user account
• Submitting a new order
• Adding a new blog post
• Uploading a file

Examples:

POST /users – Create a new user
POST /orders – Place a new order
POST /comments – Add a comment to a post

Typical Request Body:

{
  "name": "John Doe",
  "email": "john@example.com"
}

Typical Response:

{
  "id": 456,
  "name": "John Doe",
  "email": "john@example.com",
  "created_at": "2024-12-18T10:30:00Z"
}

PUT – Replace an entire resource

Purpose: Completely replace an existing resource with new data

Characteristics:

• Not safe: Modifies server state
• Idempotent: Calling it multiple times with same data has same result
• Requires sending the complete resource

When to Use:

• Completely updating a user profile
• Replacing an entire configuration
• When you have all the data for a resource

Examples:

PUT /users/123 – Replace user 123 completely
PUT /settings/notifications – Replace all notification settings

Important Difference from PATCH:

• PUT replaces the ENTIRE resource
• You must send ALL fields, not just changed ones
• Missing fields may be set to null or default values

Example:

PUT /users/123
{
  "name": "John Smith",
  "email": "john.smith@example.com",
  "age": 31,
  "address": "456 New St"
}

This replaces ALL data for user 123, not just specific fields.

PATCH – Partially update a resource

Purpose: Update only specific fields of an existing resource

Characteristics:

• Not safe: Modifies server state
• May or may not be idempotent depending on implementation
• Only sends changed fields

When to Use:

• Updating only the email address
• Changing just the user’s status
• Modifying specific fields without affecting others

Examples:

PATCH /users/123 – Update specific fields of user 123
PATCH /orders/789/status – Update only order status

Key Difference from PUT:

• PATCH updates only the fields you send
• Other fields remain unchanged
• More efficient for small updates

Example:

PATCH /users/123
{
  "email": "newemail@example.com"
}

This updates ONLY the email field. Name, age, address, etc., remain unchanged.

DELETE – Remove a resource

Purpose: Delete a resource from the server

Characteristics:

• Not safe: Permanently removes data
• Idempotent: Deleting the same resource multiple times has same effect
• May return 204 (No Content) or 200 (OK) with details

When to Use:

• Removing a user account
• Deleting a blog post
• Removing items from a cart
• Canceling an order

Examples:

DELETE /users/123 – Delete user 123
DELETE /posts/456 – Delete blog post 456
DELETE /cart/items/789 – Remove item from cart

Note: DELETE requests typically don’t have a request body.

Typical Responses:

• 204 No Content – Successfully deleted, no response body
• 200 OK – Successfully deleted with confirmation details
• 404 Not Found – Resource doesn’t exist (can’t delete what’s not there)

HEAD – Get headers only, no body

Purpose: Same as GET but returns only response headers, not the body

Characteristics:

• Safe: Doesn’t modify server state
• Idempotent: Multiple calls have same effect
• Much faster than GET since no body is transferred

When to Use:

• Checking if a resource exists without downloading it
• Verifying resource size before downloading
• Checking last-modified date
• Testing server availability
• Validating cache freshness

Examples:

HEAD /files/large-video.mp4 – Check file size without downloading
HEAD /users/123 – Verify user exists without fetching data

Use Case Example: Before downloading a large file, use HEAD to check:

• Content-Length (file size)
• Last-Modified (when it was updated)
• Content-Type (file format)

Then decide whether to proceed with GET to download it.

OPTIONS – Discover available methods

Purpose: Ask the server what HTTP methods are allowed for a specific resource

Characteristics:

• Safe: Doesn’t modify server state
• Returns allowed methods in the Allow header
• Often used in CORS (Cross-Origin Resource Sharing) preflight requests

When to Use:

• Discovering API capabilities
• CORS preflight checks (automatic in browsers)
• API exploration and documentation
• Debugging cross-origin requests

Examples:

OPTIONS /users – What methods are allowed for /users endpoint?
OPTIONS /admin/settings – Can I access this endpoint?

Typical Response:

HTTP/1.1 200 OK
Allow: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Origin: *

CORS Context: When a browser makes a cross-origin request (e.g., from app.example.com to api.example.com), it first sends an OPTIONS request to check if the cross-origin request is allowed.

Configuration Steps:

1. Locate the method dropdown to the left of the URL input box
2. Click the dropdown to see all available methods
3. Select the method appropriate for your operation:
   • Retrieving data? → GET
   • Creating something new? → POST
   • Completely replacing? → PUT
   • Updating specific fields? → PATCH
   • Removing something? → DELETE
   • Just checking? → HEAD
   • Discovering capabilities? → OPTIONS

Quick Reference:

7. Add Test Scripts

Test scripts allow you to add custom validation logic that runs automatically after a request is executed. They help you verify that the API behaves correctly and automate checks that would otherwise require manual inspection.

Why Use Test Scripts?

Without scripts, you’d manually check:

• “Is the status code 200?”
• “Does the response contain the expected fields?”
• “Is the email format valid?”
• “Did the API return the correct data?”

Test scripts automate these checks, making testing:

• Faster
• More reliable
• Repeatable
• Less prone to human error

What You Can Do with Scripts:

Verify Status Codes:

• Check if the response is successful (200, 201, 204)
• Validate error responses (400, 404, 500)
• Ensure redirects happen when expected (301, 302)

Check Response Structure:

• Verify required fields exist
• Validate data types (strings, numbers, booleans)
• Check array lengths and object properties

Validate Response Values:

• Confirm specific field values
• Check value ranges (age > 0, price < 1000)
• Validate formats (email, phone, date)

Extract and Store Data:

• Save response values as variables
• Use extracted data in subsequent requests
• Chain requests together dynamically

Check Response Times:

• Ensure APIs respond quickly enough
• Detect performance regressions
• Validate SLA compliance

Custom Business Logic:

• Verify calculated fields are correct
• Check relationships between data points
• Validate complex business rules

Configuration Steps:

1. Click on the Scripts tab in the request editor
2. Write test scripts using JavaScript syntax supported by E2E Test Automation
3. Save the request
4. When you send the request, scripts run automatically after receiving the response

Script Examples:

Example 1: Verify Status Code

// Check that the response is successful
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Example 2: Check Response Body

// Verify the response contains expected fields
pm.test("Response has required fields", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property('id');
    pm.expect(jsonData).to.have.property('name');
    pm.expect(jsonData).to.have.property('email');
});

Example 3: Validate Data Types

// Check that fields have correct data types
pm.test("Field types are correct", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.id).to.be.a('number');
    pm.expect(jsonData.name).to.be.a('string');
    pm.expect(jsonData.active).to.be.a('boolean');
});

Example 4: Verify Specific Values

// Check that specific fields have expected values
pm.test("User role is admin", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.role).to.equal('admin');
});

Example 5: Extract and Save Variables

// Save response data for use in other requests
pm.test("Extract user ID", function () {
    var jsonData = pm.response.json();
    pm.environment.set("userId", jsonData.id);
    // Now you can use {\{userId\}} in subsequent requests
});

Example 6: Check Response Time

// Verify the API responds quickly
pm.test("Response time is less than 200ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(200);
});

Example 7: Validate Array Data

// Check array properties
pm.test("Response contains multiple users", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.users).to.be.an('array');
    pm.expect(jsonData.users.length).to.be.above(0);
});

Example 8: Validate Email Format

// Check that email is in valid format
pm.test("Email is valid", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.email).to.match(/^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$/);
});

Example 9: Complex Validation

// Multiple checks in one test
pm.test("Order data is valid", function () {
    var jsonData = pm.response.json();
    
    // Check order exists
    pm.expect(jsonData.order).to.exist;
    
    // Verify order status
    pm.expect(jsonData.order.status).to.be.oneOf(['pending', 'processing', 'completed']);
    
    // Check total is positive
    pm.expect(jsonData.order.total).to.be.above(0);
    
    // Verify items exist
    pm.expect(jsonData.order.items).to.be.an('array').that.is.not.empty;
});

When Scripts Run:

• Automatically after every request execution
• Before displaying the response to you
• Results shown in the “Test Results” tab

Benefits:

• Catch regressions automatically
• Document expected behavior
• Enable continuous testing
• Build confidence in API stability
• Reduce manual verification time

8. Create Schemas

Schemas define the expected structure of your request or response data. They act as a contract that documents what fields exist, their types, and whether they’re required.

Why Use Schemas?

Data Consistency:

• Ensure all requests follow the same structure
• Prevent accidental omission of required fields
• Maintain standards across teams and environments

Validation:

• Automatically validate that data matches expectations
• Catch type mismatches (sending string instead of number)
• Verify required fields are present

Documentation:

• Self-documenting API contracts
• Help new team members understand data structures
• Serve as reference for frontend and backend teams

Easier Onboarding:

• New team members see exactly what data is expected
• Reduces confusion about API requirements
• Prevents breaking changes to API contracts

Team Collaboration:

• Frontend and backend teams agree on data structure
• QA knows what to test
• Reduces miscommunication

Use Cases:

• Large-scale applications with many endpoints
• Team-based development where multiple people work on APIs
• When you need to enforce data standards
• Preventing breaking changes in production
• API versioning and evolution

Steps to Create a Schema:

Option 1: Generate from Sample Data

1. Go to the Body tab in your request
2. Paste a sample JSON payload (example of the data structure)
3. Click “Generate Schema” button
4. E2E Test Automation analyzes the JSON and creates a schema automatically
5. The schema includes:
   • All fields from your sample
   • Inferred data types (string, number, boolean, object, array)
   • Nested structure for complex objects

Example:

Sample JSON:

{
  "name": "John Doe",
  "age": 30,
  "email": "john@example.com",
  "active": true
}

Generated Schema:

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "number" },
    "email": { "type": "string" },
    "active": { "type": "boolean" }
  },
  "required": ["name", "email"]
}

Option 2: Create Manually

You can also manually create or edit schemas:

1. Click on the Schema tab or section
2. Write or edit the schema in JSON Schema format
3. Define:
   • Field names – What properties exist
   • Data types – string, number, boolean, array, object, null
   • Required fields – Which fields must be present
   • Validations – Min/max values, string patterns, enum values

Manual Schema Example:

{
  "type": "object",
  "properties": {
    "username": {
      "type": "string",
      "minLength": 3,
      "maxLength": 20
    },
    "email": {
      "type": "string",
      "format": "email"
    },
    "age": {
      "type": "number",
      "minimum": 18,
      "maximum": 120
    },
    "role": {
      "type": "string",
      "enum": ["user", "admin", "moderator"]
    },
    "tags": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["username", "email"]
}

Schema Features You Can Define:

Data Types:

• string – Text values
• number – Numeric values (integers or decimals)
• integer – Whole numbers only
• boolean – true/false values
• array – Lists of items
• object – Nested structures
• null – Null values

String Validations:

• minLength / maxLength – String length constraints
• pattern – Regular expression pattern matching
• format – Predefined formats (email, date, uri, etc.)
• enum – List of allowed values

Number Validations:

• minimum / maximum – Value range
• exclusiveMinimum / exclusiveMaximum – Exclusive ranges
• multipleOf – Must be multiple of specified number

Array Validations:

• items – Schema for array items
• minItems / maxItems – Array length constraints
• uniqueItems – All items must be unique

Object Validations:

• properties – Define nested properties
• required – List of required properties
• additionalProperties – Allow/disallow extra fields

Benefits of Schemas:

• Automatic validation – Data is checked against schema automatically
• Clear documentation – Everyone knows the expected structure
• Prevent errors – Catch invalid data before it reaches the server
• Enable Form View – Forms are generated from schemas
• Type safety – Ensure correct data types throughout
• Version control – Track changes to API contracts over time

9. Use Form View

Form View transforms JSON schemas into user-friendly, visual forms that anyone can use—no JSON knowledge required. It’s one of E2E Test Automation’s most powerful features for enabling non-technical users to test APIs.

Why Form View?

The Problem:

• JSON can be intimidating for non-developers
• Manual JSON editing is error-prone (missing commas, brackets)
• Formatting issues waste time and cause frustration
• Business users avoid testing because of technical barriers

The Solution:

• Form View presents data as familiar form fields
• Users fill in forms instead of editing JSON
• Eliminates syntax errors completely
• Makes API testing accessible to everyone

Who Benefits:

Non-Developers:

• Product managers testing features
• QA analysts without coding background
• Business stakeholders validating requirements
• Customer support investigating issues
• Content editors managing data

Developers:

• Enable self-service testing for stakeholders
• Reduce interruptions for “simple” test runs
• Get faster feedback from non-technical team members
• Focus on development instead of running tests for others

Steps to Use Form View:

Prerequisites:

1. A schema must be linked to the request
   • Either generated from sample JSON
   • Or manually created
   • The schema defines what form fields appear

Using Form View:

1. Open the request in E2E Test Automation
2. Click “Form View” tab (next to Body tab)
3. See the generated form with fields based on your schema:
   • Text fields for strings
   • Number inputs for numeric values
   • Checkboxes for booleans
   • Dropdowns for enum values
   • Date pickers for date fields
   • Nested sections for object properties
4. Fill in values through intuitive form inputs:
   • Type in text fields
   • Check/uncheck boxes
   • Select from dropdowns
   • Pick dates from calendars
   • No need to worry about JSON formatting
5. Submit the request:
   • Click Send
   • E2E Test Automation automatically converts form data to JSON
   • The correct JSON is sent to the API
6. See the response just like any other request

Form View Features:

Field Types:

Text Input: For string fields

• Single-line text entry
• Multi-line textarea for long text
• Email inputs with validation
• URL inputs with validation

Number Input: For numeric fields

• Numeric keyboard on mobile
• Min/max constraints enforced
• Step increments for decimals

Checkbox: For boolean fields

• Simple toggle on/off
• Clear visual indication of state

Dropdown/Select: For enum fields

• Choose from predefined options
• Prevents invalid values
• Clear list of allowed choices

Date/Time Picker: For date fields

• Calendar widget for date selection
• Time picker for timestamps
• Proper format handling

Nested Sections: For object properties

• Grouped related fields
• Collapsible sections for complex structures
• Clear hierarchy visualization

Array Fields: For list properties

• Add/remove items dynamically
• Repeat field groups for each item
• Reorder items if needed

Field Indicators:

Required Fields:

• Marked with asterisk (*)
• Must be filled before submission
• Clear error messages if empty

Optional Fields:

• No asterisk
• Can be left empty
• Defaults may be applied

Field Descriptions:

• Help text explaining what to enter
• Examples of valid values
• Format requirements

Example Use Case:

Scenario: Creating a new user account

JSON View (Technical):

{
  "firstName": "John",
  "lastName": "Doe",
  "email": "john.doe@example.com",
  "age": 30,
  "role": "admin",
  "active": true,
  "preferences": {
    "newsletter": true,
    "notifications": ["email", "sms"]
  }
}

Form View (User-Friendly):

┌─ User Information ──────────────────────────┐
│ First Name *     [John____________]          │
│ Last Name *      [Doe_____________]          │
│ Email *          [john.doe@example.com____] │
│ Age              [30___]                     │
│ Role *           [Admin ▼]                   │
│                   └─ Options: user, admin,   │
│                       moderator              │
│ Active           [✓]                         │
└─────────────────────────────────────────────┘

┌─ Preferences ───────────────────────────────┐
│ Newsletter       [✓]                         │
│ Notifications    [✓] Email                   │
│                  [✓] SMS                     │
│                  [ ] Push                    │
└─────────────────────────────────────────────┘

               [Send Request]

Benefits of Form View:

Error Prevention:

• No missing commas or brackets
• No mismatched braces
• No invalid JSON syntax
• Type validation prevents wrong data types

Speed:

• Faster than editing JSON manually
• Tab through fields quickly
• No time wasted fixing formatting
• Focus on data, not syntax

Accessibility:

• Non-technical users can test independently
• Reduces dependency on developers
• Enables self-service testing
• Democratizes API testing

Clarity:

• See exactly what fields are required
• Understand data structure visually
• Get help text and examples
• Know what values are valid

Reduced Training:

• Intuitive interface needs no explanation
• Familiar form fields everyone understands
• No JSON training required
• Immediate productivity

Use Cases for Form View:

• Product managers validating feature behavior
• QA testing various data combinations
• Customer support reproducing user issues
• Business analysts testing edge cases
• Content editors managing API-driven content
• Demos and training sessions
• Rapid prototyping and iteration
• User acceptance testing (UAT)

When to Use Form View vs JSON:

Use Form View When:

• Non-technical users are testing
• Quick data entry is needed
• Preventing syntax errors is important
• Multiple variations need testing
• Onboarding new team members

Use JSON View When:

• You need precise control over data structure
• Testing malformed data intentionally
• Copying from documentation or logs
• Advanced users comfortable with JSON
• Complex nested structures with edge cases

Execution and Response

10. Send Request and View Response

After configuring all request details—URL, method, headers, body, authorization, and any test scripts—you’re ready to execute the API call and see how it responds.

Steps to Execute:

1. Review Your Configuration:
   • Double-check the URL is correct
   • Verify the HTTP method is appropriate
   • Ensure authorization is set if required
   • Confirm headers and body are configured
2. Click the “Send” Button:
   • Located prominently in the request editor
   • Initiates the HTTP request to the server
   • E2E Test Automation handles all the technical details
3. Wait for Response:
   • Usually takes milliseconds to a few seconds
   • Watch the loading indicator
   • Response appears automatically when received
4. View the Response:
   • Response panel appears below the request
   • Multiple tabs show different aspects of the response

Response Panel Components:

Body Tab

Displays the actual response data returned by the server.

What You’ll See:

• The main content of the API response
• Data in its native format (JSON, XML, HTML, plain text)

View Options:

Pretty View:

• Syntax-highlighted, formatted display
• Automatically indented for readability
• Color coding for different data types
• Expandable/collapsible sections for nested data
• Easy to scan and understand

Raw View:

• Unformatted, exactly as received
• Useful for copying exact response
• Shows special characters and encoding
• Good for debugging format issues

Preview View:

• Renders HTML responses visually
• Shows how web content appears
• Useful for testing HTML endpoints
• Displays images and formatted text

Example JSON Response:

{
  "success": true,
  "data": {
    "id": 12345,
    "name": "John Doe",
    "email": "john.doe@example.com",
    "created_at": "2024-12-18T10:30:00Z"
  },
  "message": "User retrieved successfully"
}

Benefits:

• Immediate visibility into what the API returned
• Easy to verify expected data is present
• Quick identification of errors or unexpected values
• Copy data for use in other requests or tests

Status Code

Shows the HTTP status code returned by the server, indicating the outcome of your request.

What It Means:

2xx – Success:

• 200 OK – Request succeeded, response contains data
• 201 Created – Resource successfully created
• 204 No Content – Request succeeded, no response body
• 202 Accepted – Request accepted for processing (async)

3xx – Redirection:

• 301 Moved Permanently – Resource permanently moved
• 302 Found – Resource temporarily moved
• 304 Not Modified – Cached version is still valid

4xx – Client Errors:

• 400 Bad Request – Malformed request or invalid data
• 401 Unauthorized – Authentication required or failed
• 403 Forbidden – Authenticated but not authorized
• 404 Not Found – Resource doesn’t exist
• 422 Unprocessable Entity – Valid syntax but semantic errors
• 429 Too Many Requests – Rate limit exceeded

5xx – Server Errors:

• 500 Internal Server Error – Something went wrong on server
• 502 Bad Gateway – Invalid response from upstream server
• 503 Service Unavailable – Server temporarily down
• 504 Gateway Timeout – Upstream server didn’t respond

Visual Indicator:

• Color-coded for quick recognition
• Green for success (2xx)
• Yellow for redirects (3xx)
• Red for errors (4xx, 5xx)

Why It Matters:

• Instantly know if request succeeded
• Identify problem type (client vs server)
• Guide debugging efforts
• Validate expected behavior

Execution Time

Shows how long the server took to respond to your request.

What You’ll See:

• Time in milliseconds (ms) or seconds (s)
• Example: 23.66ms, 1.2s

What It Includes:

• DNS lookup time
• Connection establishment
• Server processing time
• Data transfer time
• Total round-trip time

Why It Matters:

Performance Monitoring:

• Identify slow endpoints
• Detect performance regressions
• Compare response times across environments
• Validate SLA compliance

Optimization:

• Benchmark before and after changes
• Find bottlenecks in API calls
• Prioritize optimization efforts
• Track performance improvements

User Experience:

• Ensure acceptable load times
• Identify issues before users do
• Maintain responsive applications

Typical Response Times:

• < 100ms: Excellent, feels instant
• 100-500ms: Good, acceptable for most uses
• 500ms-1s: Noticeable, may need optimization
• > 1s: Slow, investigate performance issues
• > 5s: Very slow, likely a problem

Size

Shows the total size of the response payload.

What You’ll See:

• Size in KB (kilobytes), MB (megabytes), or bytes
• Example: 0.03 KB, 1.5 MB, 245 bytes

What It Includes:

• Response body content
• May or may not include headers (depends on implementation)

Why It Matters:

Performance:

• Large responses take longer to transfer
• Impact on mobile users with limited bandwidth
• Affects page load times and user experience

Optimization Opportunities:

• Identify bloated responses
• Suggest compression or pagination
• Optimize data structures
• Remove unnecessary fields

Data Usage:

• Important for mobile apps
• Helps manage API rate limits
• Understand bandwidth consumption

Cost Implications:

• Some cloud services charge by data transfer
• Larger responses = higher costs
• Optimization can reduce infrastructure expenses

Headers Tab

Displays all HTTP headers returned by the server in the response.

What Are Response Headers?

Headers are metadata about the response that provide:

• Content information
• Server details
• Caching instructions
• Security policies
• Custom application data

Common Response Headers:

Content-Type:

• Indicates the format of the response body
• Examples: application/json, text/html, application/xml
• Helps clients parse the response correctly

Content-Length:

• Size of the response body in bytes
• Used for progress indicators
• Helps with data transfer optimization

Server:

• Identifies the server software
• Example: nginx/1.21.0, Apache/2.4.52
• Useful for debugging server-specific issues

Date:

• When the response was generated
• Example: Thu, 18 Dec 2024 10:30:00 GMT
• Helps with debugging timing issues

Cache-Control:

• Caching directives
• Example: no-cache, max-age=3600, public
• Controls how responses are cached

Set-Cookie:

• Cookies the server wants to store
• Contains session information
• Used for authentication and state management

Access-Control-Allow-Origin:

• CORS policy for cross-origin requests
• Example: *, https://example.com
• Critical for browser-based API calls

X-RateLimit-* Headers:**

• Rate limiting information
• Example: X-RateLimit-Remaining: 99
• Helps manage API usage

Custom Headers:

• Application-specific metadata
• Example: X-Request-ID: abc-123, X-API-Version: 2.0
• Used for tracking, debugging, versioning

Why Headers Matter:

• Understand server behavior
• Debug CORS issues
• Verify caching policies
• Check security headers
• Extract session tokens or IDs

Cookies Tab

Shows any cookies that the server sent back with the response.

What Are Cookies?

Cookies are small pieces of data that servers send to be stored by the client (browser or API client). They’re used for:

• Session management
• User authentication
• Tracking preferences
• Maintaining state across requests

Cookie Information Displayed:

Name: Cookie identifier

• Example: sessionId, auth_token, user_prefs

Value: Cookie content

• Can be encrypted or plain text
• Example: abc123xyz789, eyJhbGciOiJIUzI1...

Domain: Which domain the cookie belongs to

• Example: .example.com, api.example.com
• Determines where the cookie is sent

Path: Which URL paths the cookie applies to

• Example: /, /api, /admin
• Limits cookie scope

Expires/Max-Age: When the cookie expires

• Session cookies: Deleted when browser closes
• Persistent cookies: Have specific expiration date
• Example: 2024-12-31T23:59:59Z, 86400 (seconds)

Secure: Whether cookie requires HTTPS

• true: Only sent over encrypted connections
• false: Can be sent over HTTP
• Important for security

HttpOnly: Whether JavaScript can access the cookie

• true: Protects against XSS attacks
• false: Can be accessed by scripts
• Security best practice for sensitive cookies

SameSite: CSRF protection setting

• Strict: Cookie only sent to same site
• Lax: Sent with top-level navigations
• None: Sent with all requests (requires Secure)

Why Cookies Matter:

Session Management:

• Maintain logged-in state
• Track user across requests
• Persist authentication

Testing:

• Verify correct cookies are set
• Check expiration times
• Validate security flags
• Test session persistence

Debugging:

• Identify authentication issues
• Verify session handling
• Check cookie scope
• Troubleshoot CORS problems

Test Results Tab

Displays the results of any test scripts you added to the request.

What You’ll See:

Passed Tests:

• Green checkmarks ✓
• Name of each test that passed
• Confirmation that assertions succeeded

Failed Tests:

• Red X marks ✗
• Name of each test that failed
• Error messages explaining why
• Expected vs actual values

Test Statistics:

• Total number of tests run
• Number of passed tests
• Number of failed tests
• Percentage pass rate

Example Display:

Test Results (3/4 passed)

✓ Status code is 200
✓ Response has required fields
✓ Email format is valid
✗ Response time is less than 200ms
  Expected response time to be below 200ms but got 245ms

Benefits:

• Immediate validation of API behavior
• Automatic checking without manual inspection
• Clear pass/fail indicators
• Detailed error messages for debugging
• Historical tracking of test results

Complete Response Example:

Status: 200 OK
Time: 23.66 ms
Size: 0.03 KB

[Body Tab - Pretty View]
{
  "success": true,
  "data": {
    "id": 12345,
    "name": "John Doe",
    "email": "john.doe@example.com"
  }
}

[Headers Tab]
Content-Type: application/json
Content-Length: 87
Date: Thu, 18 Dec 2024 10:30:00 GMT
Server: nginx/1.21.0

[Cookies Tab]
sessionId=xyz789abc123; Path=/; HttpOnly; Secure

[Test Results Tab]
✓ Status code is 200
✓ Response contains user data
✓ Email format is valid

Summary

E2E Test Automation provides a comprehensive and user-friendly environment for configuring, executing, and validating API requests. From detailed request setup with URLs, parameters, headers, and bodies, to sophisticated authentication methods and test automation with scripts, E2E Test Automation ensures a streamlined testing workflow.

Key Capabilities Covered:

1. Flexible Request Configuration – Complete control over every aspect of HTTP requests
2. Comprehensive Authorization – Support for all major authentication methods
3. Multiple Body Formats – JSON, XML, form data, and binary uploads
4. Test Automation – Scripts for automated validation and data extraction
5. Schema Management – Define and enforce data contracts
6. Form View – Enable non-technical users with visual interfaces
7. Detailed Responses – Comprehensive analysis of status, timing, headers, and content

Who Benefits:

• Developers – Powerful tools for precise API testing and debugging
• QA Engineers – Automation capabilities and validation scripts
• Business Users – Form views and accessible interfaces
• Teams – Collaboration through shared collections and standards
• Organizations – Consistent testing practices and quality assurance

By following the steps outlined in this guide, users of all technical backgrounds can confidently configure API requests, execute comprehensive tests, analyze detailed responses, and maintain high-quality APIs across their entire development lifecycle.

For advanced topics including business workflows, monitoring, and CI/CD integration, refer to additional sections of the E2E Test Automation documentation.