SDKs

Official client libraries for the Hostinger API in PHP, Python, and TypeScript. Each one wraps the REST API in ordinary classes and methods, so you configure your token once and call a method instead of building HTTP requests by hand.

All three are generated from the same OpenAPI specification as the Hostinger CLI and the MCP server, which means they cover every endpoint and pick up new ones automatically.

Note: Hostinger Email is a separate API with its own packages, which these three don't cover. To read or send mail from a mailbox, use the Email SDKs.

Available SDKs

Note: The package name differs from the import name in Python, and from the repository name in every language. Install hostinger-api, import hostinger_api.

Each SDK ships its own generated reference covering all 272 operations and their request and response models — see Full reference.

Authenticate

Generate an API token in hPanel → API, then keep it in an environment variable rather than in source. See Security & Access for how tokens are managed.

export HOSTINGER_API_TOKEN=<your API token>

The examples below read that variable. The SDKs don't read it automatically — you pass the token in when you build the client, so any variable name works. HOSTINGER_API_TOKEN is the name the CLI and MCP server use, so reusing it keeps one credential across every tool.

Your first request

Each example lists the websites on your account and prints their domains.

PHP

Python

The client is a context manager, so the with block closes the underlying connection pool when it exits.

TypeScript

Note: The outer data is the HTTP response body; the inner data is the array of websites inside it. Response fields keep the API's original names, so they stay snake_case in TypeScript.

How the SDKs are organized

Every SDK follows the same shape, so once you know it in one language you know it in all of them:

• One class per product area. Websites live in HostingWebsitesApi, DNS records in DNSRecordsApi, virtual machines in VPSVirtualMachinesApi, and so on.

• One method per API operation. Nothing is hand-written and nothing is missing.

• The method name is the API operation ID, adjusted to each language's conventions.

That last point is what makes the reference navigable. The operation hosting_listWebsitesV1 is the same operation everywhere — only the spelling changes:

So if you find an endpoint in the API reference, you can predict its method name — and if you're already using the CLI, the SDK method for the same task is the same operation under a different name.

Handling errors

Failed requests raise an exception carrying the HTTP status and the response body, rather than returning an error value you have to check.

In PHP, catch Hostinger\ApiException. In TypeScript, the underlying axios call rejects, so use try/catch around the await.

Staying up to date

New SDK versions are released whenever the API changes, so upgrading is how you get access to new endpoints. Pin a version in production and upgrade deliberately — the major version differs per language and doesn't track the API itself.

Full reference

Every operation, parameter, and response model is documented in each SDK's repository:

• PHP SDK reference

• Python SDK reference

• TypeScript SDK reference

When to use an SDK

An SDK is the right choice when you're building an application that manages Hostinger resources as part of its own logic — a customer dashboard that provisions websites, a reseller tool that sets up hosting and DNS per client, or a backend service managing VPS lifecycle. You get types, editor autocompletion, and a dependency you can pin and test.

For other situations, something lighter usually wins:

• One-off tasks, shell scripts, or CI — use the Hostinger CLI. No project or dependency needed.

• Working through an AI assistant — use the Hostinger Connector or the MCP server.

• A language without an SDK, or a single call — call the REST API directly.

Last updated: August 6, 2026