Privacy & processing: Processed on our secure servers
Requests are sent through our server so they can reach APIs that block browser calls (CORS). We do not store the requests or responses.
How to use API Request Tester
- Step 1
Configure Your API Request
Enter an endpoint URL, choose the HTTP method and add query parameters, headers, cookies and authentication. For write operations, prepare a JSON, XML, text or supported form body and inspect the exact target before sending.
- Step 2
Send and Inspect the Response
Send a direct browser request, or deliberately enable the optional server-side CORS proxy when required. Review status codes, response headers, cookies, formatted body, JSON tree, size and available timing details.
- Step 3
Debug, Save and Export
Diagnose response errors, test variations, save useful requests in local collections, export a cURL command or language-specific code and remove credentials before sharing screenshots or collection files.
Key features
Visual REST Request Builder
Configure methods, URLs, query parameters, headers, authentication and supported body types without writing a temporary test script.
Readable Response Inspector
Inspect status, raw or pretty JSON/XML, response headers, cookies and a browsable JSON tree to identify unexpected values.
GraphQL Query Studio
Send queries and mutations with JSON variables, and explore a schema through introspection where the endpoint permits it.
WebSocket and SSE Testing
Observe real-time WebSocket messages and Server-Sent Events, with connection and event logs for streaming applications.
Authentication Helpers
Compose Bearer or JWT bearer, API key, Basic and supplied OAuth2-token requests while keeping production access tightly controlled.
Collections and Environments
Organize repeatable API requests, history and reusable variables locally to switch development, staging and production endpoints.
cURL and Code Generation
Translate configured requests into cURL and supported client snippets for JavaScript, Python, Go, PHP and other listed targets.
CORS and Security Hints
Inspect CORS and selected request or response security patterns as troubleshooting guidance rather than penetration-testing results.
Latency and Response Metrics
Compare total response times and payload size; run light repeat-request benchmarks without claiming production load-test coverage.
Specification Imports
Reuse OpenAPI, Swagger, Postman, HAR and cURL material to start editable requests and avoid repetitive manual setup.
What Is an API Request Tester and Why Use One?
An API request tester is an interactive HTTP client for exploring an application's endpoints. Instead of creating a script for every small experiment, you configure a URL, method, headers, authentication and optional body, then inspect the response. The result contains more than data: HTTP status, content type, response headers, cookies and timing all help explain whether the server behaved as expected. MyToolSpace provides this workflow in a web browser, with reusable collections and tools for common API debugging tasks.
Developers use API testing during implementation, integration, bug investigation and release checks. A simple GET request can reveal that a filter parameter is ignored; a POST request might show why a server returns 422 for invalid input; a 401 or 403 response can expose an authentication or permission problem. Testing should be deliberate. Requests may create, update or delete actual records, and repeating a mutation can trigger more than one action. Use a permitted test environment and representative data whenever possible.
The browser-based workbench also supports GraphQL queries, WebSocket frames and Server-Sent Events. These are different communication models, so a successful HTTP response does not automatically prove that streaming subscriptions or message delivery works. Save a reproducible example containing the expected status and response shape, and separate observations from assumptions about the remote service.
Interactive API Client: Send targeted requests without installing a desktop application.
Reproducible Debugging: Capture method, URL, headers and an appropriately redacted response for review.
Test the Behavior: Check both successful requests and expected error handling.
Use Authorized Endpoints: Only test APIs and operations that you are permitted to access.
How to Test REST APIs: Methods, Headers and Request Bodies
Start by choosing the correct HTTP method. GET reads a resource, HEAD inspects response metadata, POST commonly creates resources or triggers actions, PUT commonly replaces a representation, PATCH applies a partial change, and DELETE removes a resource. OPTIONS describes communication options and often appears in cross-origin preflight handling. These are conventions, not guarantees about any particular implementation: inspect the API documentation and be aware that unsafe operations can modify live data.
A REST request is constructed from an endpoint, query parameters, headers and possibly a body. Use the Params control to encode filters, paging and sorting fields instead of concatenating strings manually. Place an expected content type in request headers and choose the matching body type. JSON is common, but XML, plain text, URL-encoded fields and multipart form fields also occur. A correctly formatted request can still fail because a required header, account permission, resource identifier or body field is missing.
Read the response as a complete HTTP exchange. A 200 response usually signals a successful request with a representation, 201 is common after creation and 204 indicates success without a response body. Do not treat an empty 204 response as a broken JSON parser. For failures, inspect server-provided validation messages, correlation identifiers and retry guidance. Keep the captured result small and remove sensitive data before sending it to a teammate.
Safe Reads: GET and HEAD are intended to avoid changing server state.
Write Carefully: POST, PUT, PATCH and DELETE can affect real records.
Body Matches Headers: Use JSON and Content-Type settings expected by the endpoint.
Inspect Status and Body: A success status alone does not prove the returned fields are correct.
API Authentication: Bearer Tokens, API Keys, Basic Auth and JWTs
Authentication identifies the caller; authorization controls which operations that caller can perform. In the Auth panel, MyToolSpace offers helpers for Bearer or JWT bearer tokens, API keys, Basic authentication and OAuth2 access-token values. An API key may belong in a header or a query parameter according to the provider's documentation, although header placement is generally preferable when supported. Basic authentication encodes credentials with Base64; Base64 is not encryption, so protect it with HTTPS.
A JSON Web Token often contains a header, payload and signature. Decoding the readable portions can show claims such as issuer, audience, subject and expiration. It does not confirm authenticity or permissions, because verification requires the applicable signature-checking process and trusted keys. An expired token may cause a 401 error, while a valid token without permission commonly leads to 403. Inspect token scope and audience rather than simply replacing it with an administrator credential.
Use environment variables for reusable values such as base_url and token, but remember that local browser storage is not a secure vault. Avoid saving production credentials in shared collections or exporting fully resolved cURL commands. The optional CORS proxy sends the selected request through an additional server, so do not route confidential secrets through that relay without reviewing the applicable security policy. For signatures such as AWS Signature Version 4, prepare authorization with an approved external SDK when necessary.
401 vs 403: Distinguish missing or invalid credentials from insufficient privileges.
JWT Decode Is Not Verify: Reading claims is not cryptographic signature validation.
Limit Token Exposure: Prefer scoped, short-lived development credentials.
Review Proxy Routing: Direct requests and proxied requests have different data paths.
GraphQL API Testing, Variables and Schema Introspection
GraphQL lets clients request a specific set of fields from a schema. The workbench can send a query or mutation to an endpoint and include variables serialized as JSON. Set the correct URL and authentication, then inspect both the data and errors properties in the returned object. GraphQL commonly uses HTTP 200 even when application-level field errors exist, making it important not to classify every 200 response as a pass.
Schema introspection can expose available types, fields and arguments when permitted by the remote server. This is useful for finding the correct operation or understanding an unfamiliar integration. Many production environments restrict introspection, so a failed query is not proof that the API is unavailable. Use the vendor's published schema or development endpoint instead. Also distinguish validation errors from business-rule errors and transport-level failures.
GraphQL subscriptions typically involve an application-specific WebSocket protocol and a negotiated handshake. The generic WebSocket panel lets you connect and inspect frames, but it does not automatically implement every graphql-ws subscription flow. Use a specialized subscription client when you need protocol-managed GraphQL operations or automatic reconnection semantics.
Send Variables as JSON: Keep dynamic inputs outside the operation string.
Read GraphQL Errors: Inspect the body even when transport status is 200.
Introspection Depends on Server: Disabled introspection is a legitimate production configuration.
Subscriptions Need Protocol Support: Raw WebSocket frames are not a full GraphQL subscription client.
Understanding Browser CORS Errors and the Optional Proxy
Cross-Origin Resource Sharing determines whether JavaScript on one web origin may read a response from another origin. An API can function perfectly for server-side callers and still reject a browser client's origin. Browsers also send preflight OPTIONS requests for certain methods and headers. If the CORS response does not allow the origin, method or required headers, the browser may block the result before the application can inspect it.
The direct mode sends requests from your browser to the target service. MyToolSpace lists an optional server-side CORS proxy for cases where cross-origin browser requests are blocked. Enabling it deliberately changes the network path: the relay can receive request data, including headers and bodies. Use permitted development endpoints and avoid highly sensitive tokens with a proxy unless its handling terms meet your requirements. A relay cannot fix missing privileges or an incorrect resource URL.
CORS and network errors can appear similar in a JavaScript client. Look at browser developer tools, the server's access-control response headers and the URL scheme. Mixed-content policies can block insecure HTTP calls from an HTTPS site. Cross-origin security rules also limit which headers and fine-grained timing fields the tool can display. Do not claim that hidden data is empty or that a 0 ms timing was measured.
Direct Mode: Target receives your browser-origin request.
Proxy Mode: Selected traffic is relayed via a server and changes privacy considerations.
Preflight Check: Inspect OPTIONS handling and Access-Control-Allow headers.
CORS Is Not Authentication: A permitted origin does not grant user authorization.
Postman Alternative: When a Browser API Tester Is Enough
Searches for an online Postman alternative, REST client or free API tester often come from a need to send a request quickly without installation. MyToolSpace fits interactive exploration: configure a method and URL, inspect JSON or XML, manage local collections, use variables, generate request snippets and import common API artifacts. A browser-based tool is especially convenient for debugging a public API or verifying one staging endpoint during development.
A dedicated desktop or hosted API platform can be better when a team needs shared synchronized workspaces, scheduled uptime monitoring, managed mock servers, deep automated assertion runners or very large automated test suites. MyToolSpace does not represent those hosted capabilities as present. Browser CORS restrictions also make some API testing workflows easier from a server-side environment. Choose the right tool based on permissions, collaboration needs and execution model rather than marketing comparisons.
Terms such as API Request Tester, online REST client, Postman alternative and GraphQL tester describe relevant search intent. MyToolSpace branding phrases such as iLoveMyToolSpace, smallmytoolspace, cloudmytoolspace and pdfmytoolspace are discovery variations, not independently verified popular keywords or affiliations with other products. Natural language and genuine feature differences are more useful than repeating unrelated brand phrases.
Browser Workbench: Good for interactive calls, response inspection and code snippets.
Hosted API Platform: Better for shared monitoring and larger automated team workflows.
Use Meaningful Alternative Terms: Explain capabilities rather than suggesting official integrations.
Avoid Keyword Stuffing: Prioritize genuinely helpful developer documentation.
Privacy, Local Storage and Responsible API Testing
Requests sent directly from a web browser go to the target API; that target may record request logs, identifiers and uploaded content. MyToolSpace states that local collections, history and environments are stored in browser storage. This is convenient but not equivalent to encrypted enterprise secrets management. People with access to the same browser profile or device may be able to inspect locally saved values. Clear temporary requests and tokens after testing confidential material.
The optional CORS proxy changes the data flow because the selected request is relayed through a server. Review the tool's current documentation and privacy policy before routing sensitive payloads or production authorization headers through it. Never assume that a product described as browser-based prevents the destination API from receiving your data. Also consider whether a generated export or screenshot might include secrets, account identifiers or customer records.
Test only services you own or are authorized to evaluate. Avoid brute-force authentication, unauthorized access attempts, denial-of-service traffic and destructive experiments. Rate limits and service terms apply even when testing with a free online client. For security validation, use dedicated approved tools and a defined scope; a simple HTTP-header security score does not establish that an API is secure.
Redact Before Sharing: Scrub Authorization headers, cookies and personally identifying data.
Protect Local History: Use a separate browser profile for sensitive test contexts.
Honor API Terms: Respect scopes, quotas and permissible testing practices.
Understand Data Routes: Browser-local configuration differs from sending requests to remote services.
HTTP Methods for API Testing
Choose a method based on intended behavior and confirm semantics in the API documentation.
| Typical purpose | Body expectation | Testing caution | |
|---|---|---|---|
| GET | Read a resource | Usually none | Avoid assuming a GET implementation is side-effect-free |
| POST | Create or execute an action | Often JSON or form data | Repeated calls may produce duplicate changes |
| PUT | Replace a resource | Usually a full representation | Omitted fields may be reset |
| PATCH | Update selected fields | Partial update document | Patch semantics depend on media type |
| DELETE | Remove a resource | Usually none | Test only expendable development records |
| HEAD | Inspect metadata | No response body | Check headers and status |
| OPTIONS | Discover server communication options | Usually none | Important for browser CORS preflight |
HTTP Status Codes at a Glance
A response code should always be interpreted alongside body, headers and API-specific rules.
| Meaning | What to inspect | |
|---|---|---|
| 200 | Request completed | Validate returned data and expected shape |
| 201 | Resource created | Check location or resource ID |
| 204 | Success with no body | Do not try to parse missing JSON |
| 301/302 | Redirect | Verify destination and auth propagation |
| 400 | Malformed request | Check query, headers and payload |
| 401 | Unauthenticated | Verify credentials and token expiry |
| 403 | Forbidden | Review scopes and resource permissions |
| 404 | Not found | Check endpoint and resource identifier |
| 409 | Conflict | Inspect concurrency or duplicate resource state |
| 422 | Validation issue | Read field-specific error details |
| 429 | Rate limited | Respect retry advice and provider quotas |
| 500/502/503 | Server or upstream failure | Inspect logs and use safe retries |
API Authentication Options
Credential format and placement vary by API.
| Typical placement | Important safety check | |
|---|---|---|
| Bearer / JWT | Authorization header | Use HTTPS and verify scope and expiry |
| API key | Provider-defined header, sometimes query | Avoid placing secrets in URLs |
| Basic | Authorization Basic header | Base64 is not encryption |
| OAuth2 token | Bearer access token | An existing access token is not a full OAuth authorization flow |
| Precomputed signature | Authorization header | Sign with an approved external SDK when necessary |
| Cookies | Cookie header or browser cookie jar | Inspect SameSite, Secure and HttpOnly behavior |
REST, GraphQL, WebSocket and SSE
Match the testing workflow to the transport.
| Interaction | Useful inspection | Main limitation | |
|---|---|---|---|
| REST HTTP | Request and response | Status, headers, JSON/XML | Browser CORS and authentication |
| GraphQL HTTP | Query or mutation to endpoint | data, errors, variables, introspection | HTTP 200 can include application errors |
| WebSocket | Persistent bidirectional messages | Frames and connection state | Application protocol and handshakes vary |
| SSE | Server-pushed event stream | Event names, values, connection | EventSource header and method constraints |
Browser-Based Tester vs Other API Testing Workflows
Select based on security controls, collaboration and performance requirements.
| Strength | Limit | |
|---|---|---|
| MyToolSpace browser workbench | Quick interactive API exploration and exports | CORS restrictions and no hosted team monitors |
| Desktop API client | Local client integration and richer workflows | Requires installation or local configuration |
| Hosted API platform | Shared workflows, monitoring and collaboration | Accounts, data-sharing and plan constraints |
| Command-line cURL | Scriptable and reproducible HTTP calls | Less visual response exploration |
| Load-testing framework | Controlled concurrency and performance studies | Requires careful traffic design and authorization |
Common use cases
Backend API Developers
Test newly implemented CRUD endpoints, inspect validation responses, compare authentication states and save repeatable staging calls before merging a change.
Frontend Engineers
Reproduce Fetch or Axios failures, investigate CORS messages and verify JSON response shapes before integrating UI screens.
Third-Party Integrators
Test documented partner endpoints with limited-scope credentials, verify query parameter encoding and generate starter snippets for integration code.
QA and Test Analysts
Create a compact collection of positive and negative cases, preserve expected statuses and export reproducible examples for regression work.
Application Security Reviewers
Check HTTPS usage, response-header hints, cookie flags and credential placement within an authorized assessment; escalate to full security testing when required.
DevOps and SRE Teams
Smoke-test staging deployments, confirm health endpoint behavior and compare lightweight response latency without treating it as production monitoring.
Data and API Analysts
Explore pagination, nested JSON arrays, field names and common error envelopes while documenting the expected data contract.
Students Learning APIs
Practice GET and POST, understand HTTP statuses, decode test JWT claims and learn the difference between REST, GraphQL and streaming transports.
Technical Support Teams
Reproduce a customer-reported error with sanitized requests, export safe cURL examples and share actionable diagnostics with developers.
Practical tips
Start With a Nonproduction Endpoint
Use a controlled development or staging URL first. A POST, PATCH or DELETE can modify data; confirm the method and target before sending.
Use Least-Privilege Test Tokens
Prefer short-lived scopes and synthetic accounts. Do not copy administrative or customer credentials into screenshots, logs or shared exports.
Check the Actual URL After Variables Resolve
A wrong base_url or path parameter can point a test at production. Inspect substitutions and query encoding before using destructive methods.
Compare HTTP Status and Response Body
A 200 response can return incorrect fields, and GraphQL can return errors with 200. Validate data semantics, not just the colored status indicator.
Treat 204 as a Successful Empty Response
If no body is expected, do not report a JSON parsing error as an API defect. Inspect headers and workflow results instead.
Keep CORS Proxy Use Deliberate
Use direct browser mode first. A proxy relays selected headers and bodies through a server; review privacy requirements before sending secrets.
Redact HAR, cURL and Collection Exports
Captured requests and generated commands may embed tokens and cookies. Replace secret values before uploading them to tickets or repositories.
Record Expected Error Cases
Test 400, 401, 403, 404 and 429 intentionally when authorized. Well-defined failures are an important part of API quality.
Measure Comparable Latency Samples
Keep environment, payload and authentication consistent. Browser timing is affected by connection and network conditions and cannot replace load testing.
Inspect JWT Claims Without Trusting Them
Decoded issuer, audience and expiry values are informative, but only cryptographic verification can establish token signature validity.
Avoid Benchmarking Mutating Requests
Repeated POST or DELETE operations can create duplicates or remove data. Benchmark safe idempotent endpoints or controlled mocks instead.
Keep Local Browser History Clean
Collections and environment variables may remain on the device. Remove sensitive values after testing and use an appropriate browser profile.
Frequently asked questions
What is MyToolSpace API Request Tester?
It is a browser-based API testing workbench for constructing HTTP requests and inspecting responses. You can work with REST endpoints, GraphQL queries, WebSocket messages and SSE event streams, as well as local collections, environment values and code exports. It supports exploratory debugging; it does not promise a hosted automated monitoring service.
How do I test a REST API online?
Choose GET or another appropriate method, enter the full endpoint, add expected parameters, headers and credentials, then send. Inspect the actual status, formatted and raw body, headers, cookies and timing. Use a staging endpoint when the request might change records, and verify the API documentation for required payload formats.
Is the API Request Tester free to use?
The MyToolSpace page presents the browser workbench as a free tool without account installation requirements. Usage is still governed by the API provider’s rate limits, permissions and service terms. The page itself may change, so refer to the current workbench for any new conditions.
Can I use it instead of Postman?
For quick REST or GraphQL calls, response inspection, request collections, variable substitution and code generation, it can serve as a lightweight browser-based Postman alternative. It does not replace shared cloud workspaces, scheduled monitoring, hosted mocks or full automated enterprise API testing pipelines.
Which HTTP methods can I test?
The workbench describes common methods including GET, POST, PUT, PATCH, DELETE, HEAD and OPTIONS. Check the method required by the endpoint because a service may reject otherwise valid requests with 405 Method Not Allowed. Sending a write method can change server state, so use authorized test resources.
Can I send JSON in a POST request?
Yes. Select POST or another body-supporting method and the JSON body option, then provide syntactically valid JSON. Verify that Content-Type is application/json and that the server expects your exact property names and value types. A well-formed JSON document can still fail business validation.
What is a CORS error?
CORS is a browser security policy controlling which web origins may read cross-origin responses. A server may respond normally to command-line clients while blocking a browser call if it lacks the required Access-Control-Allow headers or preflight policy. Check origin, methods, headers and HTTPS before assuming an endpoint is offline.
Can the built-in proxy bypass CORS?
The optional proxy relays selected requests from a server-side route, which can avoid the browser’s direct cross-origin restrictions. It introduces an additional data handler; avoid sensitive production tokens unless you have checked applicable privacy and security requirements. A proxy cannot fix invalid authentication, an unavailable service or server-side authorization rules.
Are my API requests completely private?
Direct requests travel from your browser to the destination API, which may log them. MyToolSpace says request history and environments are kept in local browser storage, but that is not a secure vault. If you enable the optional CORS proxy, the selected traffic also passes through a server. Protect credentials in all three contexts.
How do I add a Bearer token?
Open authentication settings, select Bearer token and enter a scoped test token or a variable reference. The request sends an Authorization: Bearer value. Use HTTPS, check token expiration and avoid exporting a command with a real secret embedded. A 401 can indicate expiration, invalid formatting or missing credentials.
Can I test Basic Auth and API keys?
Yes. The workbench lists Basic authentication and API keys placed in a header or query parameter according to the API contract. Basic Auth uses Base64 and is not encrypted by itself. Prefer HTTPS and headers for sensitive values where the service supports them, because URL parameters may appear in logs.
Does the tool handle OAuth2 login?
It can apply an existing OAuth2 access token as described by the live page. It should not be treated as a complete hosted authorization-code flow or a general OAuth identity provider. Acquire tokens through the legitimate provider flow or approved development tooling, then apply them with correct scopes and expiry handling.
Can I decode and verify JWT tokens?
The JWT inspection interface decodes header and payload claims so you can inspect expiry, issuer and audience fields. Decoding does not verify the signature or establish that the token was issued by a trusted provider. Verify cryptographic authenticity in an appropriate authentication library or server.
Can I run GraphQL queries and mutations?
Yes. Set a GraphQL request body, provide your operation and JSON variables, then send to the correct GraphQL endpoint. Inspect both data and errors in the JSON response because logical GraphQL errors may occur with HTTP 200. Mutations can change live resources and deserve the same caution as write operations in REST.
What is GraphQL introspection?
Introspection is a set of GraphQL queries that describe a service’s schema, including its types, fields and arguments. The workbench can request and display this information if the API allows it. Many production servers disable introspection; use published documentation if permission is unavailable.
Can I test GraphQL subscriptions?
The tool has a generic WebSocket panel for observing messages, but it does not automatically complete every GraphQL subscription protocol handshake. If your application relies on graphql-ws or another specific protocol, use a compatible subscription client to test end-to-end subscription semantics.
Can I test a WebSocket API?
Open the realtime panel, provide a ws:// or wss:// URL and connect. Send permitted application messages and inspect the returned frames and state changes. Successful transport connection does not prove an application-level subscription or authentication handshake has completed.
Can I inspect Server-Sent Events?
Yes. The SSE mode opens a server-pushed event stream and logs incoming events. Native EventSource commonly uses GET and cannot freely attach custom authorization headers, so some secured feeds need an alternative test environment. Confirm that server buffering and network reconnect behavior do not disguise missing messages.
Can I export request code in Python or JavaScript?
The workbench advertises code generation for eighteen targets including JavaScript Fetch and Axios, Python requests, PHP, Go and more. Exported examples capture the configured request, but you should add application-specific timeouts, retries, robust error handling and secure token retrieval before using them in production.
Can I save requests and reuse environment variables?
Yes. Local collections and environments support reusable URL and token placeholders. Switch between test environments carefully, because a valid variable can accidentally send a write operation to production. Local persistence depends on browser storage and can be lost when browser data is cleared.
Why do I get 403 Forbidden?
A 403 often means the caller is identified but lacks permission for the requested resource or operation. Inspect required scopes, account roles and authorization policies. Changing the HTTP method or guessing other resource IDs is not an appropriate substitute for obtaining permission.
What does HTTP 429 mean?
The API is limiting request frequency or quota. Respect the provider’s retry policy and any Retry-After header. Reduce repetitive testing or benchmarking rather than trying to evade a rate limit. Rate limiting can also depend on account, IP address or endpoint-specific quotas.
Can I see detailed DNS, TLS and TTFB timing?
Detailed phases may be visible through the browser Resource Timing API when the target provides the necessary timing permissions, such as Timing-Allow-Origin. Otherwise cross-origin privacy rules can hide them. Total round-trip time and payload size are still useful, but hidden phases should not be reported as measured.
Is the benchmark tool a full API load tester?
No. The workbench offers a lightweight repeated-request benchmark with summary latency and success measures. Browser concurrency, client variability and CORS limit realism. Use a dedicated authorized load-testing solution to evaluate throughput, sustained concurrency or service capacity.
Can I use this tool to test API security?
You can review selected security headers, transport, cookie attributes, credential placement and CORS patterns. Those findings are rule-based hints rather than proof that the service is secure or a comprehensive vulnerability assessment. Obtain authorization before testing and use dedicated processes for security assurance.
How does this tool compare with Hoppscotch or Insomnia?
All can be considered in the broad API-client category, but features, privacy models, supported protocols and collaboration arrangements vary by product and version. MyToolSpace emphasizes quick browser requests, local collections, imports and code snippets. Do not assume it offers hosted monitoring or the same team workspace controls as other products.
Troubleshooting
| Problem | Likely cause | What to do |
|---|---|---|
| Request fails with a CORS error | The remote API does not permit the browser page’s origin, method or request headers, or rejects preflight OPTIONS. | Inspect Access-Control-Allow-Origin, -Methods and -Headers on the server. Use a permitted backend test client or deliberately enable the optional proxy only for nonsensitive requests after reviewing its data route. |
| API request returns 401 Unauthorized | Authorization header is absent, malformed, expired or issued for the wrong audience or environment. | Confirm the chosen auth scheme, token format, expiry, scopes and target base URL. Replace the token through the approved provider flow rather than trying random credentials. |
| API returns 403 Forbidden | The caller may be authenticated but lacks permission, a required role or a resource-level authorization grant. | Review the endpoint policy and obtain the appropriate scope from the API owner. Use an authorized test account; do not bypass restrictions by guessing resource identifiers. |
| Server returns 405 Method Not Allowed | The endpoint does not accept the selected HTTP method or a route is mapped differently. | Check endpoint documentation and allowed methods. Use GET for reads and only send write methods when the operation is expected and authorized. |
| POST returns 400 or 422 | JSON is malformed, required fields are missing, a field type is wrong or a business validation rule failed. | Validate JSON syntax, Content-Type, schema-required properties and response error details. Reproduce with a minimal valid example before adding optional fields. |
| Response appears empty after 204 | The server deliberately returned No Content, so there is no payload to pretty-print. | Treat 204 as success when documented. Inspect status, headers and the expected downstream resource state instead of requiring an empty JSON object. |
| JSON viewer reports invalid JSON | The body might be malformed JSON, HTML from a proxy, plain text, or valid data served with an incorrect content type. | Switch to the raw response, inspect Content-Type and the first meaningful characters. Correct server output or view it as text instead of forcing JSON parsing. |
| Bearer token works in cURL but not browser | The browser may be blocked by CORS, preflight headers or a different origin-specific authentication rule. | Compare request method, origin and Authorization headers. Use the server CORS configuration or a legitimate server-side workflow rather than exposing new secrets. |
| GraphQL returns HTTP 200 but no usable data | The GraphQL response may contain an errors array, missing fields or null values due to schema or resolver problems. | Inspect data and errors together, validate query names and variable types, and request only fields supported by the endpoint schema. |
| WebSocket connection closes immediately | The endpoint, protocol negotiation, auth handshake, origin restrictions or server idle policy may be incompatible. | Try a known supported wss endpoint, inspect close codes and server logs, and follow the application’s required handshake sequence. |
| WebSocket connects but no messages arrive | The service may require an application-level subscription, initial payload or particular event trigger. | Review the protocol and send a documented subscription message. An open socket proves only transport connectivity, not that a business event has been registered. |
| SSE connection opens without events | The server may not be publishing events, an intermediary may buffer output or the event stream may need auth that EventSource cannot provide through custom headers. | Verify text/event-stream behavior and server flush configuration. Test with an accessible development feed and inspect server-side event publishing. |
| Optional CORS proxy returns an error | The relay may reject an unsafe destination, exceed request limits or be unable to reach the remote host. | Check that the endpoint is publicly reachable and permitted. Do not attempt to bypass relay restrictions; use an authorized direct or local server-side client. |
| Response headers or cookies are missing | Browsers expose only permitted cross-origin headers, and HttpOnly cookies are not readable through page scripts. | Inspect network tools and server CORS exposure settings. Do not assume the server omitted an invisible header or cookie. |
| Detailed timing fields show no numbers | Cross-origin resource timing is restricted unless the server explicitly allows timing disclosure. | Use total elapsed time as a broad indicator and request Timing-Allow-Origin configuration if you control the service; do not invent DNS or TLS measurements. |
| Imported OpenAPI endpoint points to the wrong host | The specification may contain a production server URL, relative server value or missing environment substitution. | Inspect imported server settings and path placeholders. Replace the target with an approved staging URL before any write operation. |
| Imported cURL request behaves differently | Shell quoting, local files, cookies, binary flags or unsupported command options may not translate perfectly into browser requests. | Compare the rendered method, URL, headers and body against the original command. Use a terminal for unsupported binary and shell-specific behavior. |
| Collection disappears after browser cleanup | Request collections and environment values are stored in browser storage that may be cleared by privacy settings. | Export sanitized collections before clearing browser data. Treat local storage as a convenience rather than a guaranteed backup service. |
| Rate limit response appears during repeated tests | The API provider enforces request quotas, account limits or protection against rapid polling. | Stop repeating calls, obey Retry-After if supplied and ask the owner for a suitable testing quota. Avoid trying to evade the rate limit. |
| Exported collection contains sensitive tokens | The export or generated cURL may include resolved environment values, authentication headers or cookies. | Revoke or rotate exposed tokens when necessary, redact the exported file and replace secrets with documented variable placeholders before sharing. |
Developer Tools
Explore More Tools
Go ad-free & unlock more
- Zero ads, faster focused workflow
- Unlimited history & saved presets
- Batch processing & exports