Authentication overview

ReqRes provides a mock REST API designed primarily for testing and development purposes. Unlike many production APIs, ReqRes does not implement traditional authentication mechanisms such as API keys, OAuth tokens, or session-based authentication for its core mock data endpoints. This design choice simplifies its use for scenarios like frontend prototyping, educational demonstrations, and initial API integration testing, where a fully authenticated backend is not yet available or necessary ReqRes documentation overview.

The service offers endpoints for common operations like user listing, creation, update, and deletion, all of which are publicly accessible. This means that any client can interact with the API without presenting credentials. Consequently, developers should not transmit or store any sensitive or production-critical data when interacting with ReqRes, as the data is not secured by an authentication layer.

Developers often use ReqRes to simulate API responses and test UI components that interact with dynamic data. Its public nature removes the overhead of credential management during the early stages of development, allowing for faster iteration and focus on client-side logic. For projects that eventually require secure data exchange, integrating a proper authentication scheme with a production-ready backend becomes essential once beyond the mock API stage.

Supported authentication methods

ReqRes does not support explicit authentication methods. The API is designed for public access, meaning all endpoints are available without the need for API keys, OAuth tokens, or other credential types. This design aligns with its purpose as a mock API for development and testing.

The table below summarizes the typical authentication methods found in APIs and clarifies their applicability to ReqRes:

Method When to Use (General) Security Level (General) Applicability to ReqRes
No Authentication Public, non-sensitive data, mock APIs, educational purposes. Low (publicly accessible) Primary method for ReqRes. All endpoints are publicly accessible.
API Key Access control for specific users/applications, rate limiting, analytics. Medium (key secret must be protected) Not applicable; ReqRes does not use API keys.
OAuth 2.0 Delegated authorization, third-party application access to user resources. High (token-based, granular permissions) Not applicable; ReqRes does not support OAuth 2.0. For an example of OAuth 2.0 implementation, see the Google Identity OAuth 2.0 documentation.
Basic Authentication Simple username/password for internal APIs, low-security scenarios. Low to Medium (credentials base64 encoded) Not applicable; ReqRes does not use Basic Authentication.
Bearer Token (e.g., JWT) Stateless authentication for REST APIs, microservices. Medium to High (token secret must be protected) Not applicable; ReqRes does not use bearer tokens.

For operations that typically require authentication, such as creating or updating resources, ReqRes allows these actions without any credentials. For instance, a POST request to /api/users will successfully create a mock user, and a PUT request to /api/users/2 will update a mock user, without any authentication headers. This behavior is consistent across all documented ReqRes endpoints ReqRes API reference.

Getting your credentials

Since ReqRes operates without an authentication layer, there are no credentials to obtain, manage, or renew. Developers do not need to sign up, generate API keys, or go through an OAuth authorization flow to use the service. This significantly reduces the setup time for new projects or learning exercises.

To start using ReqRes, you can directly make HTTP requests to its endpoints. For example, to retrieve a list of users, you would simply make a GET request to https://reqres.in/api/users. There is no need for headers such as Authorization or query parameters like apiKey.

This approach is beneficial for:

  • Rapid Prototyping: Quickly build and test frontend components that interact with an API.
  • Educational Purposes: Ideal for teaching API concepts without the complexity of authentication.
  • Initial API Integration: Verify basic HTTP request/response handling before a real backend is ready.

While the absence of credentials simplifies access, it also means that any data sent to ReqRes should be considered public and non-sensitive. It is not suitable for handling real user data or confidential information.

Authenticated request example

As ReqRes does not require authentication, an "authenticated" request is indistinguishable from any other request. The following examples demonstrate how to interact with the ReqRes API using common HTTP methods, illustrating that no authentication headers or parameters are included.

Get a list of users (GET)

To retrieve a list of users, send a GET request to the /api/users endpoint. This example fetches the first page of users.

GET /api/users?page=1 HTTP/1.1
Host: reqres.in
Accept: application/json
fetch('https://reqres.in/api/users?page=1')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

Create a new user (POST)

To create a new user, send a POST request to the /api/users endpoint with the user's details in the request body. No authentication is needed.

POST /api/users HTTP/1.1
Host: reqres.in
Content-Type: application/json

{
    "name": "morpheus",
    "job": "leader"
}
fetch('https://reqres.in/api/users', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    name: 'morpheus',
    job: 'leader'
  }),
})
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

Update an existing user (PUT)

To update an existing user, send a PUT request to the /api/users/{id} endpoint with the updated details. This example updates user with ID 2.

PUT /api/users/2 HTTP/1.1
Host: reqres.in
Content-Type: application/json

{
    "name": "morpheus",
    "job": "zion resident"
}
fetch('https://reqres.in/api/users/2', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    name: 'morpheus',
    job: 'zion resident'
  }),
})
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

Delete a user (DELETE)

To delete a user, send a DELETE request to the /api/users/{id} endpoint. This example deletes user with ID 2.

DELETE /api/users/2 HTTP/1.1
Host: reqres.in
fetch('https://reqres.in/api/users/2', {
  method: 'DELETE',
})
  .then(response => {
    if (response.status === 204) {
      console.log('User deleted successfully');
    } else {
      console.log('Deletion failed with status:', response.status);
    }
  })
  .catch(error => console.error('Error:', error));

These examples demonstrate that all interactions with ReqRes are performed without any authentication overhead, making it straightforward for quick testing and development.

Security best practices

While ReqRes itself does not require authentication, adhering to security best practices is still crucial when integrating it into your development workflow. The primary consideration stems from its public nature: any data sent to ReqRes is not secured and should not be treated as private.

  • Never Send Sensitive Data: This is the most critical rule. Do not use ReqRes to transmit or store any personally identifiable information (PII), financial data, health information, or any other confidential data. ReqRes is a mock API, and its data is publicly accessible and not encrypted at rest or in transit beyond standard HTTPS.
  • Use for Mock Data Only: Restrict your usage of ReqRes to synthetic or dummy data that holds no real-world value or sensitivity. This aligns with its purpose as a tool for frontend and API prototyping.
  • Separate Development and Production Environments: Ensure that your application's production environment uses a properly authenticated and secured backend API, not ReqRes. Configure your development tools (e.g., environment variables) to switch between ReqRes for local testing and your actual backend for deployment.
  • Understand API Security Fundamentals: Even though ReqRes is unauthenticated, developers should still understand the principles of API security, such as the importance of HTTPS, input validation, and proper authentication/authorization mechanisms for real-world applications. Resources like the OAuth 2.0 specification and the HTTP Authentication specification provide foundational knowledge for building secure APIs.
  • Rate Limiting (Self-Imposed): While ReqRes does not explicitly state rate limits, it's good practice to avoid excessive requests that could overwhelm any public service. Treat it as a shared resource and make requests responsibly during testing.
  • Client-Side Security: If your client-side application interacts with ReqRes, ensure it follows general web security best practices, such as sanitizing user input and preventing cross-site scripting (XSS) attacks, even if the data source is a mock API.
  • Review Network Traffic: Use browser developer tools or network sniffers to inspect requests and responses when working with ReqRes. This helps verify that no unintended sensitive data is being sent and that your application handles mock responses correctly.

By following these guidelines, developers can leverage ReqRes effectively for its intended purpose without introducing security vulnerabilities into their broader development practices or inadvertently exposing sensitive information.