</>
ProtocolCodes

Mock Response Generator

Generate realistic mock HTTP responses with custom status codes and headers. Copy ready-to-use curl commands and code snippets.


                


                
                

                    

                


                
                

                    

                


                
                

                    

                

            

        


        
        

            

                Quick Test:
                Use httpbin.org/status/
                to test how your code handles this status code.
            

        


    












    
How to Use

    
    
        
        
  1. 
            1
            
    
                Select a status code to mock
                
    Choose the HTTP status code you want the mock response to return. Common choices include 200, 201, 400, 401, 403, 404, 422, 429, and 500 for testing different handling paths.
    
            
    
        
    2. 
        
        
  2. 
            2
            
    
                Customize headers and body
                
    Set custom response headers such as Content-Type, Retry-After, or WWW-Authenticate and provide an optional JSON response body. The generator pre-fills RFC-compliant defaults for each status code.
    
            
    
        
    3. 
        
        
  3. 
            3
            
    
                Copy the mock endpoint URL
                
    Use the generated endpoint URL in your application, test suite, or Postman collection to trigger the exact response scenario you need without setting up a real server.
    
            
    
        
    4. 
        
    








    
About

    

        
Realistic mock HTTP responses are a foundational tool for building resilient API clients and testing error-handling code paths that rarely occur in happy-path development. Rather than requiring a full test server, a mock response generator lets you inject any status code, header combination, and response body into your integration tests, frontend application, or API client library with minimal setup.
The Mock Response Generator adheres strictly to RFC 9110 (HTTP Semantics) for response structure and RFC 9457 (Problem Details for HTTP APIs) for error body formatting. Each status code comes pre-populated with its RFC-mandated headers — 401 includes WWW-Authenticate, 405 includes Allow, 429 includes Retry-After, and 304 omits the body entirely as required. This means your generated mocks are not just syntactically valid but semantically correct, catching client bugs that loose mocking would miss.
Common workflows include testing retry logic against 503 with Retry-After headers, verifying that authentication flows correctly handle 401 WWW-Authenticate challenges, and ensuring pagination code handles 204 No Content gracefully. Teams using contract testing frameworks like Pact or consumer-driven contract testing can use the generated mock definitions as starting points, and CI pipelines can drive the mock endpoints to validate client behavior before any backend code is written.

    








    
FAQ

    

        
        

            
                How do I test rate limiting (429) responses in my API client?
                
            
            
A properly formed 429 Too Many Requests response (RFC 6585 §4) should include a Retry-After header indicating when the client may retry, either as a number of seconds (Retry-After: 60) or an HTTP-date. The mock generator creates a 429 response with a realistic Retry-After value and an optional RateLimit-* header family (IETF draft-ietf-httpapi-ratelimit-headers). Test that your client backs off correctly and does not immediately retry.

        

        
        

            
                What headers must a 401 Unauthorized response include?
                
            
            
RFC 9110 §15.5.2 requires that a 401 Unauthorized response include a WWW-Authenticate header identifying the authentication scheme (e.g., WWW-Authenticate: Bearer realm="api"). Omitting this header violates the specification and breaks standard HTTP clients and browsers that rely on it to display the correct login prompt or trigger token refresh flows. The mock generator adds the appropriate WWW-Authenticate header by default.

        

        
        

            
                When should a mock return 503 versus 500?
                
            
            
RFC 9110 §15.6.4 defines 503 Service Unavailable for temporary outages — the server is alive but cannot handle the request right now due to overload or scheduled maintenance. A 503 should include a Retry-After header. Use 500 Internal Server Error for unexpected failures where the cause is unknown and no retry guidance can be given. Testing both paths helps ensure your client implements circuit-breaking for temporary failures while surfacing 500s as bugs.

        

        
        

            
                What is the correct response body format for error codes?
                
            
            
RFC 9457 (Problem Details for HTTP APIs, July 2023) defines a standard JSON error format with Content-Type: application/problem+json, including fields type (URI), title, status, detail, and instance. This supersedes RFC 7807. Adopting this format makes errors machine-readable for API gateways, monitoring tools, and client libraries. The mock generator can produce RFC 9457-compliant error bodies for any 4xx or 5xx code.

        

        
        

            
                How do I simulate a 304 Not Modified response correctly?
                
            
            
A 304 Not Modified (RFC 9110 §15.4.5) response must not include a message body. It should contain the same headers a 200 would have carried for the resource — specifically ETag, Cache-Control, and Last-Modified — so the client can update its cache entry. The mock generator emits a header-only 304 with matching conditional headers (ETag and Last-Modified) that your client can use to validate its cache implementation.