HTTP Request Builder

Build and Test HTTP Requests

Construct HTTP requests with custom headers, body, and authentication. Test APIs without writing code.

Request Components

• Method: GET, POST, PUT, PATCH, DELETE
• Headers: Custom headers, Content-Type, Authorization
• Body: JSON, form data, raw text
• Authentication: Basic, Bearer, API key

Response Viewer

See status, headers, body, timing, and size. Format JSON responses automatically.

Understanding HTTP Communication

HTTP (Hypertext Transfer Protocol) is the foundation of data communication on the web. Every time you visit a website or use an API, HTTP requests and responses are exchanged between clients (browsers, apps) and servers.

The Request-Response Cycle

1. Client sends request - Your browser or application sends an HTTP request to a server
2. Server processes request - The server receives, validates, and processes the request
3. Server sends response - The server returns an HTTP response with status code and data
4. Client handles response - Your application receives and processes the response

Anatomy of an HTTP Request

Every HTTP request consists of:

• Request Line: Method (GET, POST, etc.) + URL + HTTP version
• Headers: Metadata about the request (Content-Type, Authorization, etc.)
• Body: Data being sent (optional, typically for POST/PUT/PATCH)

Anatomy of an HTTP Response

Every HTTP response consists of:

• Status Line: HTTP version + Status code + Status text
• Headers: Metadata about the response (Content-Type, Cache-Control, etc.)
• Body: Data being returned (HTML, JSON, XML, etc.)

Common HTTP Methods

• GET - Retrieve data (read-only, no body)
• POST - Create new resources (includes body with data)
• PUT - Update/replace entire resource (includes body)
• PATCH - Partially update resource (includes body with changes)
• DELETE - Remove resource (body optional)
• OPTIONS - Query allowed methods (used for CORS preflight)
• HEAD - Retrieve headers only (like GET but no body returned)

Understanding HTTP Status Codes

Status codes are three-digit numbers that indicate the result of an HTTP request. They're grouped into five categories:

2xx Success

The request was successfully received, understood, and accepted.

• 200 OK - Standard success response
• 201 Created - Resource successfully created (typically POST)
• 202 Accepted - Request accepted for processing (async)
• 204 No Content - Success but no content to return (typically DELETE)

3xx Redirection

Further action is needed to complete the request.

• 301 Moved Permanently - Resource has new permanent URL
• 302 Found - Resource temporarily at different URL
• 304 Not Modified - Cached version is still valid (use cache)
• 307 Temporary Redirect - Temporary redirect, keep method

4xx Client Errors

The request contains bad syntax or cannot be fulfilled.

• 400 Bad Request - Invalid syntax (check JSON, required fields)
• 401 Unauthorized - Authentication required or failed
• 403 Forbidden - Authenticated but no permission
• 404 Not Found - Resource doesn't exist at this URL
• 405 Method Not Allowed - HTTP method not supported for this endpoint
• 429 Too Many Requests - Rate limit exceeded

5xx Server Errors

The server failed to fulfill a valid request.

• 500 Internal Server Error - Generic server error
• 502 Bad Gateway - Invalid response from upstream server
• 503 Service Unavailable - Server temporarily unavailable (maintenance, overload)
• 504 Gateway Timeout - Upstream server didn't respond in time

Debugging with Status Codes

• 2xx = Success - continue with response data
• 4xx = Check your request (syntax, auth, permissions)
• 5xx = Server problem (check API status, try again later)

API Authentication Methods

APIs use various authentication methods to verify client identity and authorize access. Here are the most common approaches:

1. Bearer Token Authentication

Most common for modern APIs, especially OAuth 2.0 and JWT-based authentication.

How it works:

• Obtain a token from the authentication server
• Include token in Authorization header: Authorization: Bearer {token}
• Server validates token and processes request

When to use: Modern APIs, OAuth 2.0, JWT tokens, mobile apps, SPAs

Security: Token should be short-lived; use HTTPS; never commit tokens to source control

2. Basic Authentication

Simple username and password authentication using base64 encoding.

How it works:

• Encode username:password as base64
• Include in Authorization header: Authorization: Basic {base64}
• Server decodes and validates credentials

When to use: Simple APIs, development, internal tools, initial authentication to get token

Security: Must use HTTPS (credentials are only encoded, not encrypted); consider as legacy for public APIs

3. API Key Authentication

Simple key-based authentication, often for service-to-service communication.

How it works:

• Obtain API key from service provider
• Include in custom header (e.g., X-API-Key: {key}) or query parameter
• Server validates key and processes request

When to use: Third-party integrations, public APIs with usage tracking, service accounts

Security: Treat like passwords; rotate regularly; use different keys for dev/prod; monitor usage

4. OAuth 2.0

Industry-standard protocol for authorization, used by major platforms (Google, GitHub, etc.).

How it works:

• User authorizes your app via consent screen
• Receive authorization code
• Exchange code for access token (and refresh token)
• Use access token for API requests

When to use: Third-party integrations, user data access, delegated authorization, social login

Security: Use PKCE for mobile/SPA; validate state parameter; short-lived access tokens with refresh tokens

5. Custom Authentication

Some APIs use proprietary authentication schemes.

Examples:

• HMAC signatures (AWS Signature V4)
• Digest authentication
• Certificate-based authentication
• Session cookies

When to use: When required by specific API

Security: Follow API documentation carefully; understand signature generation; use official SDKs when available

Best Practices

1. Always use HTTPS - Never send credentials over unencrypted HTTP
2. Store securely - Use environment variables, never hardcode credentials
3. Rotate regularly - Change keys and tokens periodically
4. Least privilege - Request only the permissions you need
5. Monitor usage - Track API key usage to detect compromise
6. Separate environments - Different credentials for dev/staging/production

Effective API Debugging Strategies

Debugging API requests efficiently requires a systematic approach. Follow these best practices to identify and resolve issues quickly.

1. Start Simple, Add Complexity

Begin with the simplest possible request and add complexity incrementally.

Basic debugging flow:

1. Test with minimal request (no headers, no auth, no body)
2. Add authentication
3. Add required headers
4. Add request body
5. Add optional parameters

This isolates exactly what's causing the failure.

2. Read Error Messages Carefully

Error messages contain valuable information - don't skip them!

What to look for:

• Status code (tells you the category of error)
• Error message in response body (specific issue description)
• Error codes (API-specific error identifiers)
• Field-level errors (which parameters are invalid)

3. Verify Request Format

Ensure your request matches API expectations.

Common format issues:

• JSON syntax errors - Missing commas, quotes, brackets
• Content-Type mismatch - Body is JSON but header says XML
• Required fields missing - Check API documentation
• Invalid data types - String instead of number, etc.
• Encoding issues - Special characters not properly encoded

4. Authentication Troubleshooting

Authentication errors (401, 403) are common but usually straightforward to fix.

401 Unauthorized checklist:

• ✓ Is authentication header present?
• ✓ Is token/key valid and not expired?
• ✓ Is authentication scheme correct (Bearer vs Basic)?
• ✓ Is token properly formatted (spaces, encoding)?

403 Forbidden checklist:

• ✓ Does your account have necessary permissions?
• ✓ Are required scopes granted?
• ✓ Is the resource accessible to your account level?
• ✓ Are there IP restrictions or rate limits?

5. Compare with Working Examples

When stuck, compare your request with known working examples.

Resources to check:

• API documentation examples
• Official SDK source code
• Community examples (StackOverflow, GitHub)
• API provider's sandbox/test environment
• cURL examples from documentation

6. Inspect Response Headers

Response headers provide important clues beyond the status code.

Useful headers to check:

• Content-Type - Format of response body
• X-RateLimit-* - Rate limit status
• WWW-Authenticate - Authentication requirements
• Retry-After - When to retry after rate limit
• Cache-Control - Caching directives

7. Test in Isolation

Eliminate variables to identify the root cause.

Isolation techniques:

• Test same request in different tools (browser, Postman, cURL)
• Test from different networks (CORS issues)
• Test with different credentials (permission issues)
• Test different endpoints (API-wide vs endpoint-specific)

8. Use Developer Tools

Browser developer tools provide deep insights.

What to check:

• Network tab - See actual request/response
• Console - JavaScript errors, CORS messages
• Application tab - Cookies, localStorage
• Security tab - Certificate issues

9. Handle Rate Limits

APIs often implement rate limiting to prevent abuse.

Rate limit strategies:

• Check rate limit headers (X-RateLimit-Remaining)
• Implement exponential backoff for retries
• Cache responses to reduce requests
• Use webhooks instead of polling where possible
• Upgrade to higher tier if consistently hitting limits

10. Document and Learn

Keep a debugging log to identify patterns.

What to document:

• Problem description
• Error messages
• Steps taken
• Solution that worked
• Time spent

This builds a personal knowledge base for faster debugging in the future.

Common Mistakes to Avoid

❌ Don't guess - Read error messages and documentation ❌ Don't ignore status codes - They tell you where to look ❌ Don't skip validation - Validate JSON before sending ❌ Don't reuse tokens indefinitely - Check expiration ❌ Don't test in production first - Use dev/staging environments ❌ Don't hardcode credentials - Use environment variables

Quick Debugging Checklist

When a request fails, check in this order:

1. ✓ Status code (what category of error?)
2. ✓ Response body (what's the specific error?)
3. ✓ Request URL (correct endpoint?)
4. ✓ HTTP method (GET vs POST vs PUT?)
5. ✓ Authentication (present and valid?)
6. ✓ Headers (Content-Type, Accept, etc.)
7. ✓ Request body (valid JSON/XML, required fields?)
8. ✓ CORS (testing from browser?)
9. ✓ Rate limits (exceeded quota?)
10. ✓ API status (is the service up?)

Understanding CORS (Cross-Origin Resource Sharing)

CORS is a browser security feature that can block requests from this tool to certain APIs. Understanding CORS is essential for web-based API testing.

What is CORS?

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts web pages from making requests to domains different from the one serving the page.

Origin = Protocol + Domain + Port

Examples:

• https://inventivehq.com:443 (this tool)
• https://api.example.com:443 (target API)
• Different origins → CORS applies

Why Does CORS Exist?

Without CORS, malicious websites could make requests to any API using your credentials (cookies, tokens) stored in the browser. CORS prevents this by requiring APIs to explicitly allow cross-origin requests.

How CORS Works

Simple Requests (GET, HEAD, POST with simple content types)

1. Browser sends request with Origin: https://inventivehq.com header
2. Server responds with Access-Control-Allow-Origin header
3. If origins match (or server allows all with *), browser allows the response
4. If origins don't match, browser blocks the response

Preflight Requests (PUT, DELETE, custom headers)

1. Browser sends OPTIONS request (preflight) before actual request
2. Preflight includes intended method and headers
3. Server responds with allowed methods, headers, origins
4. If preflight succeeds, browser sends actual request
5. If preflight fails, browser blocks the actual request

Common CORS Headers

Request headers:

• Origin: https://inventivehq.com - Where request is coming from
• Access-Control-Request-Method: PUT - Intended method (preflight)
• Access-Control-Request-Headers: authorization - Custom headers (preflight)

Response headers:

• Access-Control-Allow-Origin: * - Allowed origins (or specific domain)
• Access-Control-Allow-Methods: GET, POST, PUT - Allowed methods
• Access-Control-Allow-Headers: authorization - Allowed custom headers
• Access-Control-Allow-Credentials: true - Allow cookies/auth
• Access-Control-Max-Age: 3600 - Cache preflight response (seconds)

Why Is My Request Blocked?

CORS Error Messages:

• "No 'Access-Control-Allow-Origin' header present"
• "CORS policy: Response to preflight request doesn't pass access control check"
• "CORS header 'Access-Control-Allow-Origin' missing"

Common Causes:

1. API doesn't support CORS at all
2. API allows specific origins, but not inventivehq.com
3. API allows only simple requests (GET, POST), blocking PUT/DELETE
4. API doesn't allow custom headers (Authorization, X-API-Key)
5. Preflight response missing required CORS headers

Solutions for CORS Issues

Option 1: Configure API to Allow CORS

If you control the API, add CORS headers to responses:

Access-Control-Allow-Origin: https://inventivehq.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

Option 2: Use Browser Extension (Development Only)

Install a CORS extension to disable CORS checks during testing.

⚠️ Warning: Only use for development! Never disable CORS in production.

Popular extensions:

• CORS Unblock (Chrome)
• Allow CORS: Access-Control-Allow-Origin (Firefox)

Option 3: Test with Desktop Tools

Desktop tools (Postman, Insomnia, cURL) aren't subject to CORS because they're not browsers.

When to use:

• Testing APIs that don't support CORS
• Production testing with sensitive credentials
• Automated testing and CI/CD

Option 4: Use Proxy Server

Route requests through a server you control to bypass browser CORS.

How it works:

1. Your browser → Your proxy server (same origin, no CORS)
2. Your proxy server → Target API (server-to-server, no CORS)
3. Proxy returns response to browser

⚠️ Security: Only proxy to APIs you trust. Proxies can see credentials.

CORS Best Practices for API Developers

Don't Use Wildcard with Credentials

❌ Bad:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

✓ Good:

Access-Control-Allow-Origin: https://inventivehq.com
Access-Control-Allow-Credentials: true

Be Specific with Allowed Methods and Headers

Only allow what's necessary:

Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type, Authorization

Handle Preflight Requests

Respond to OPTIONS requests with appropriate CORS headers and 200 status.

Cache Preflight Responses

Use Access-Control-Max-Age to reduce preflight requests:

Access-Control-Max-Age: 86400

Validate Origin

Don't just echo the Origin header. Validate against allowlist:

const allowedOrigins = [
  "https://inventivehq.com",
  "https://app.example.com"
];

if (allowedOrigins.includes(request.headers.origin)) {
  response.headers["Access-Control-Allow-Origin"] = request.headers.origin;
}

Testing CORS Configuration

Use this tool to test CORS behavior:

1. Simple GET request - Should work if API allows any CORS
2. POST with JSON - Tests Content-Type: application/json
3. Custom headers - Tests Authorization, X-API-Key, etc.
4. PUT/DELETE - Tests preflight handling

Check browser developer tools Network tab for:

• OPTIONS preflight requests
• CORS-related errors
• Response headers (Access-Control-*)

CORS is Not Authentication

CORS doesn't prevent unauthorized access - it only controls which origins can access responses in a browser.

• CORS protects users, not APIs
• APIs still need authentication/authorization
• CORS can't prevent direct API calls (cURL, Postman, etc.)