REST API for testing and prototyping.
Realistic data for users, posts, comments and todos. Bearer-token auth, customizable rate limits, JSON or XML. Spend your time on the app you are building, not on stubbing data.
curl -H "Authorization: Bearer ACCESS-TOKEN" \
https://gorest.co.in/public/v2/users
const res = await fetch("https://gorest.co.in/public/v2/users", {
headers: { Authorization: "Bearer ACCESS-TOKEN" }
});
const users = await res.json();
import requests
r = requests.get(
"https://gorest.co.in/public/v2/users",
headers={"Authorization": "Bearer ACCESS-TOKEN"}
)
users = r.json()
require "net/http"
require "json"
uri = URI("https://gorest.co.in/public/v2/users")
req = Net::HTTP::Get.new(uri)
req["Authorization"] = "Bearer ACCESS-TOKEN"
res = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) { |h| h.request(req) }
users = JSON.parse(res.body)
req, _ := http.NewRequest("GET", "https://gorest.co.in/public/v2/users", nil)
req.Header.Set("Authorization", "Bearer ACCESS-TOKEN")
res, _ := http.DefaultClient.Do(req)
defer res.Body.Close()
Click Run to see live data.Skip the backend. Ship the frontend.
Realistic users, posts, comments, and todos, wired up exactly like a real app. So you can build, test, and demo without waiting on an API team.
Sign in with GitHub, Google, or Microsoft, generate a token, ship.
Names, emails, posts, and comments seeded daily. Relations behave like a real app.
Append the format, set the header, or stick with the default. Both response styles supported.
Rate limit per access token is yours to configure. Pagination headers do the heavy lifting.
From zero to first request in 60 seconds.
Create a token
Generate a personal access token. Set its rate limit and revoke it any time you want.
Make requests
Send your token in theAuthorizationheader. Try anything in the console first if you want to play.
Four resources, fully wired up.
Linked the way a real product is. Users own posts and todos; posts collect comments.
Users
People profiles with name, email, gender and status.
The API surface, at a glance.
Pick a version that matches how your client expects to receive data.
Users
Nested
/public/v2/users?name=kumar. Pagination is controlled withpageandper_page (max 100).What you get back.
Same data, two shapes. v2 hands you the resource directly; v1 wraps it with pagination metadata.
v1 is deprecated and will be retired on 2 June 2027. New integrations should use v2; existing v1 calls keep working until then and now carry Deprecation and Sunset response headers.
[
{
"id": 4521,
"name": "Avani Iyer",
"email": "avani.iyer@example.com",
"gender": "female",
"status": "active"
},
{
"id": 4520,
"name": "Pranav Kapoor",
"email": "pranav.kapoor@example.com",
"gender": "male",
"status": "inactive"
}
]
{
"meta": {
"pagination": {
"total": 2884,
"pages": 289,
"page": 1,
"limit": 10,
"links": {
"previous": null,
"current": "https://gorest.co.in/public/v1/users?page=1",
"next": "https://gorest.co.in/public/v1/users?page=2"
}
}
},
"data": [
{
"id": 4521,
"name": "Avani Iyer",
"email": "avani.iyer@example.com",
"gender": "female",
"status": "active"
}
]
}
Bearer tokens, the boring kind.
RESTful APIs are stateless. Send a token with every request, over HTTPS. We support two transports:
- Authorization header:
Authorization: Bearer <token> - Query parameter:
https://gorest.co.in/public/v2/users?access-token=%3Ctoken%3E
v2 is direct. v1 wraps.
Body is the resource ({} or [{}]). Pagination in headers. Status code carries response code.
Body is{ meta:, data: }.metacarries pagination,datacarries results.
Know your budget.
X-RateLimit-LimitRequests per minute allowed for this token.X-RateLimit-RemainingRequests left in the current window.X-RateLimit-ResetSeconds until the window resets.
Page through anything.
X-Pagination-TotalTotal matching results.X-Pagination-PagesTotal pages.X-Pagination-PageCurrent page.X-Pagination-LimitResults per page.
Standard HTTP, no surprises.
What each status code actually means, and the most common reason you'll see it.
GET succeeded; the resource is in the response body.
POST/PUT created a new resource; Location header points to it.
DELETE or empty-body update; we have nothing else to say.
Your cached copy is still fresh; do not refetch.
Body or query string is malformed; check syntax and required fields.
Authorization header is missing or the token is invalid.
Authenticated, but this token cannot access this resource.
No resource at this URL, or it is owned by another token.
The URL exists but does not accept this HTTP verb.
Content-Type is not application/json or application/xml.
JSON parsed but failed validation; body lists the bad fields.
Rate limit exhausted; retry after X-RateLimit-Reset seconds.
Something broke on our side. Quote X-Request-Id when reporting.
Down for maintenance or briefly overloaded. Retry in a bit.
Quick answers.
The questions we hear most. If yours is not here, ask in Q&A.
Yes. No credit card, no usage tier. The trade-off is that data resets daily, and you should not store anything sensitive.
All non-system records are wiped and reseeded every 24 hours, so the API always has fresh, realistic data.
No. Records you create or modify are only visible to your access token. Public seed data is shared.
Either. Append .json or .xml to any endpoint, or set the Accept header. Both v1 and v2 support both formats.
Default is 90 requests per minute per access token. Customize per token from your account (allowed range 1 to 300).
Open a question in the Q&A section or use the Contact form. We read everything.
Yes. Add ?delay=1500 to any GET request to simulate up to 5 seconds of latency, or ?force_status=500 (also 400, 401, 403, 404, 405, 415, 422, 429, 503) to make the API return that error. Each comes with X-Simulated-Delay-Ms or X-Simulated-Status response headers.
Yes. CORS is open and preflight requests are answered. Just keep your access token off the client: use it from a server, a browser extension you control, or a sandbox where exposure is acceptable.