> For the complete documentation index, see [llms.txt](https://docs.hostinger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hostinger.com/api-reference/sdks.md).

# SDKs

Official client libraries for the [Hostinger API](/api-reference/overview.md) 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](/api-reference/cli.md) 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](/api-reference/email-sdks.md).

## Available SDKs

| Language   | Install                                  | Import as                  | Requires     |
| ---------- | ---------------------------------------- | -------------------------- | ------------ |
| PHP        | `composer require hostinger/api-php-sdk` | `Hostinger\Api\…`          | PHP 8.2+     |
| Python     | `pip install hostinger-api`              | `import hostinger_api`     | Python 3.10+ |
| TypeScript | `npm install hostinger-api-sdk`          | `from 'hostinger-api-sdk'` | axios 1.8+   |

> **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](#full-reference).

## Authenticate

Generate an API token in [hPanel → API](https://hpanel.hostinger.com/api), then keep it in an environment variable rather than in source. See [Security & Access](/account/security.md) for how tokens are managed.

```bash
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

```php
<?php
require_once __DIR__ . '/vendor/autoload.php';

$config = Hostinger\Configuration::getDefaultConfiguration()
    ->setAccessToken(getenv('HOSTINGER_API_TOKEN'));

$websites = new Hostinger\Api\HostingWebsitesApi(config: $config);

$response = $websites->listWebsitesV1();

foreach ($response->getData() as $website) {
    echo $website->getDomain(), PHP_EOL;
}
```

### Python

```python
import os
import hostinger_api

configuration = hostinger_api.Configuration(
    access_token=os.environ["HOSTINGER_API_TOKEN"]
)

with hostinger_api.ApiClient(configuration) as client:
    websites = hostinger_api.HostingWebsitesApi(client)
    response = websites.list_websites_v1()

    for website in response.data:
        print(website.domain, website.is_enabled)
```

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

### TypeScript

```typescript
import { Configuration, HostingWebsitesApi } from 'hostinger-api-sdk';

const configuration = new Configuration({
  accessToken: process.env.HOSTINGER_API_TOKEN,
});

const websites = new HostingWebsitesApi(configuration);

const { data } = await websites.listWebsitesV1();

for (const website of data.data ?? []) {
  console.log(website.domain, website.is_enabled);
}
```

> **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:

| Surface    | Listing websites                  |
| ---------- | --------------------------------- |
| REST       | `GET /api/hosting/v1/websites`    |
| PHP        | `$api->listWebsitesV1()`          |
| Python     | `api.list_websites_v1()`          |
| TypeScript | `api.listWebsitesV1()`            |
| CLI        | `hostinger hosting websites list` |

So if you find an endpoint in the [API reference](/api-reference/overview.md), 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.

```python
from hostinger_api.rest import ApiException

try:
    response = websites.list_websites_v1()
except ApiException as e:
    print(f"Request failed with status {e.status}")
```

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](https://github.com/hostinger/api-php-sdk/tree/main/docs)
* [Python SDK reference](https://github.com/hostinger/api-python-sdk/tree/main/docs)
* [TypeScript SDK reference](https://github.com/hostinger/api-typescript-sdk/tree/main/docs)

## 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](/api-reference/cli.md). No project or dependency needed.
* **Working through an AI assistant** — use the [Hostinger Connector](/hostinger-connector/overview.md) or the MCP server.
* **A language without an SDK, or a single call** — call the [REST API](/api-reference/overview.md) directly.

***

*Last updated: August 6, 2026*