HTTP 418 — I’m a teapot
HTTP 418 began as an April Fools joke in 1998 (HTCPCP, the Hyper Text Coffee Pot Control Protocol) and became the web’s beloved easter egg. Some real services return it to deflect unwanted automated traffic.
When 418 shows up
- Easter-egg endpoints celebrating the protocol joke.
- Anti-scraping traps that serve 418 to suspected bots.
Mocking a 418 response
A response with this status can be faked end to end with a local mock rule — no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):
{
"method": "GET",
"path": "/brew",
"status": 418,
"delay": 420,
"enabled": true,
"body": {
"error": "teapot",
"message": "This is a teapot; coffee cannot be brewed."
}
}Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.
Frequently asked questions
What does HTTP 418 mean?
By the joke’s definition, a teapot cannot brew coffee, so the request is refused forever. In production use it signals a deliberately playful refusal.
How can I test a 418 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 418. The example configuration above returns this response after the listed delay, so the client exercises its 418 handling exactly as it would against a live server.
Related status codes
Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.