close
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Support & feedback

Where to ask questions, report bugs and request features for the Hostinger API — and what to include so the problem can be traced.

Questions about the API, bug reports and feature requests go to the hostinger/api repository, which is where the OpenAPI specification behind these docs is published.

You want to
Go to

Report a bug or unexpected response

Request an endpoint or a field

Ask how to do something

Reach the API team directly

Get help with your account, billing or a website

Hostinger support — available 24/7

The last row matters: the API repository is for the API itself. A suspended domain, a failed payment or a site that won't load is a support question, not an API one, and 24/7 support will resolve it faster.

What to include in a report

A report that can be reproduced gets fixed. Include:

  • The correlation ID. Every error response carries a correlation_id field and an x-correlation-id header — see Errors. This is the single most useful thing you can provide; it lets the team find your exact request in the logs.

  • The endpoint and method, for example POST /api/hosting/v1/websites.

  • The status code and full response body.

  • A minimal request that reproduces it — a curl command is ideal.

  • Which tool you used, if not raw HTTP: the CLI, an SDK and its version, or the MCP server.

Redact your API token and any personal data before posting. Correlation IDs are safe to share; tokens are not. If a token has appeared anywhere public, revoke it in hPanel → API.

Reporting a problem with these docs

Errors in the endpoint reference come from the OpenAPI specification and should be raised on the API repository — fixing them there fixes the CLI, the SDKs and the MCP server at the same time.

For anything else on this site — a guide that's out of date, a broken link, a missing explanation — email devs@hostinger.com with the page URL.

Tracking changes

The API is versioned per endpoint — /v1/ in the path — and new endpoints are added without breaking existing ones. The specification carries a version number in its info.version field, which increments on every publish.

To see what changed, fetch the specification and diff it against your last copy. The SDKs and the CLI are regenerated and released alongside it, so upgrading them is how you pick up new endpoints.


Last updated: September 10, 2026

Last updated

Was this helpful?