FAQ

Stubpoint creates temporary API responses for apps, webhooks, demos, and integration tests. Choose the body, status code, content type, safe headers, and methods; Stubpoint gives you a public URL.

Endpoints expire after 7 days without traffic.

You can return JSON, XML, plain text, HTML, or CSV by choosing the response content type.

Yes. Call /status/{code} with any status from 200 through 599.

No. For quick checks, use the built-in status endpoints and simple presets: /status/418, /json, /xml, /text, or /headers.

• Endpoints expire after 7 days without traffic.
• Response bodies can be up to 64 KiB.
• Each endpoint can use up to 20 safe custom headers.
• Response delay can be set from 0 through 10000 milliseconds for best-effort simulated latency.
• Each client can keep up to 25 active endpoints.

Endpoint restrictions are subject to change. Restriction changes apply going forward where relevant. Stored response content is not rewritten by a policy change.

The testing recipe library has practical templates for frontend states, validation errors, pagination, auth responses, webhooks, data formats, and edge cases.

Using a recipe only pre-fills the form. Nothing is stored until you create an endpoint.

No. Stubpoint returns the body you enter. That makes it useful for malformed payloads, client error handling, and mismatched content types.

No. Anyone with the URL can call the endpoint. Do not store secrets or production-critical data.

Yes. Stubpoint uses rate limits to keep the service usable. If you hit a limit, slow down and retry shortly.

Paid plans are being considered and may be available in the future for higher usage, team features, longer retention, custom domains, and production workflows.

No. Stubpoint is a best-effort testing tool with no SLA, no retention guarantee, and no availability guarantee.

Yes. Use POST /api/endpoints to create an endpoint with the same fields and limits as the website form. See the API documentation.