@hostinger/sdk 1.54.3 → 1.56.0

package/docs/HostingFilesApi.md

@@ -11,7 +11,7 @@ All URIs are relative to *https://developers.hostinger.com*
 # **generateUploadURLV1**
 > HostingV1FilesUploadUrlResource generateUploadURLV1(hostingV1FilesGenerateUploadUrlRequest)
 
-Generate a file browser upload URL with authentication credentials for uploading files directly to a website\'s file storage.  Returns `url`, `auth_key` and `rest_auth_key`. Use these to upload a file to the website\'s `public_html` directory via the TUS resumable upload protocol (TUS 1.0.0). Send `X-Auth: {auth_key}` and `X-Auth-Rest: {rest_auth_key}` headers on every request below.  1. Create the upload: `POST` to `{url}/{relative_file_path}?override=true` with headers    `upload-length: {file size in bytes}` and `upload-offset: 0`. Expect `201 Created`. 2. Upload the file: send the file bytes to the same location (any TUS 1.0.0 client, or    `PATCH` requests with an `upload-offset` header tracking progress) until complete.  `relative_file_path` is the destination path inside `public_html`, e.g. `app.zip`.  Instead of a TUS client, plain `curl` also works: ``` FILE=app.zip SIZE=$(stat -f%z \"$FILE\")   # stat -c%s on Linux  curl -i -X POST \"{url}/${FILE}?override=true\" \\   -H \"X-Auth: {auth_key}\" \\   -H \"X-Auth-Rest: {rest_auth_key}\" \\   -H \"Tus-Resumable: 1.0.0\" \\   -H \"Upload-Length: ${SIZE}\" \\   -H \"Upload-Offset: 0\" # -> 201 Created  curl -i -X PATCH \"{url}/${FILE}?override=true\" \\   -H \"X-Auth: {auth_key}\" \\   -H \"X-Auth-Rest: {rest_auth_key}\" \\   -H \"Tus-Resumable: 1.0.0\" \\   -H \"Content-Type: application/offset+octet-stream\" \\   -H \"Upload-Offset: 0\" \\   --data-binary \"@${FILE}\" # -> 204 No Content, Upload-Offset response header equals SIZE when done ```
+Generate a file browser upload URL with authentication credentials for uploading files directly to a website\'s file storage.  While the website is still being set up (`status: running` on the list website setups endpoint) this endpoint returns 409 with a `Retry-After` header: wait that many seconds and retry, or poll the website setups until the status is `completed`.  Returns `url`, `auth_key` and `rest_auth_key`. Use these to upload a file to the website\'s `public_html` directory via the TUS resumable upload protocol (TUS 1.0.0). Send `X-Auth: {auth_key}` and `X-Auth-Rest: {rest_auth_key}` headers on every request below.  1. Create the upload: `POST` to `{url}/{relative_file_path}?override=true` with headers    `upload-length: {file size in bytes}` and `upload-offset: 0`. Expect `201 Created`. 2. Upload the file: send the file bytes to the same location (any TUS 1.0.0 client, or    `PATCH` requests with an `upload-offset` header tracking progress) until complete.  `relative_file_path` is the destination path inside `public_html`, e.g. `app.zip`.  Instead of a TUS client, plain `curl` also works: ``` FILE=app.zip SIZE=$(stat -f%z \"$FILE\")   # stat -c%s on Linux  curl -i -X POST \"{url}/${FILE}?override=true\" \\   -H \"X-Auth: {auth_key}\" \\   -H \"X-Auth-Rest: {rest_auth_key}\" \\   -H \"Tus-Resumable: 1.0.0\" \\   -H \"Upload-Length: ${SIZE}\" \\   -H \"Upload-Offset: 0\" # -> 201 Created  curl -i -X PATCH \"{url}/${FILE}?override=true\" \\   -H \"X-Auth: {auth_key}\" \\   -H \"X-Auth-Rest: {rest_auth_key}\" \\   -H \"Tus-Resumable: 1.0.0\" \\   -H \"Content-Type: application/offset+octet-stream\" \\   -H \"Upload-Offset: 0\" \\   --data-binary \"@${FILE}\" # -> 204 No Content, Upload-Offset response header equals SIZE when done ```
 
 ### Example
 
@@ -59,6 +59,7 @@ const { status, data } = await apiInstance.generateUploadURLV1(
 |**200** | Success response |  -  |
 |**422** | Validation error response |  -  |
 |**401** | Unauthenticated response |  -  |
+|**409** | Conflict response. &#x60;Retry-After&#x60;, when present, is the number of seconds to wait before retrying. |  * Retry-After - Seconds to wait before retrying the request <br>  |
 |**500** | Error response |  -  |
 
 [[Back to top]](#) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to Model list]](../README.md#documentation-for-models) [[Back to README]](../README.md)

package/docs/HostingV1OnboardingsOnboardingResource.md

@@ -0,0 +1,28 @@
+# HostingV1OnboardingsOnboardingResource
+
+
+## Properties
+
+Name | Type | Description | Notes
+------------ | ------------- | ------------- | -------------
+**domain** | **string** | Domain of the website being set up. | [default to undefined]
+**username** | **string** | Hosting account username. | [default to undefined]
+**status** | **string** | `running` while the website is still being set up, `completed` once the setup has finished, `failed` when it stopped before finishing or has not reported progress for over an hour. | [default to undefined]
+**created_at** | **string** | When the setup was requested. | [default to undefined]
+**updated_at** | **string** | When the setup last reported progress. | [default to undefined]
+
+## Example
+
+```typescript
+import { HostingV1OnboardingsOnboardingResource } from '@hostinger/sdk';
+
+const instance: HostingV1OnboardingsOnboardingResource = {
+    domain,
+    username,
+    status,
+    created_at,
+    updated_at,
+};
+```
+
+[[Back to Model list]](../README.md#documentation-for-models) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to README]](../README.md)

package/docs/HostingV1WebsitesWebsiteResource.md

@@ -7,7 +7,7 @@ Name | Type | Description | Notes
 ------------ | ------------- | ------------- | -------------
 **domain** | **string** | Website domain. Null for U4S websites with no domain attached. | [optional] [default to undefined]
 **vhost_type** | **string** | Virtual host type. Only present for CloudLinux websites. | [optional] [default to undefined]
-**is_enabled** | **boolean** | Whether website is enabled | [optional] [default to undefined]
+**is_enabled** | **boolean** | True unless the website is suspended. Not a readiness signal: a website that is still being set up is enabled too, see the list website setups endpoint. | [optional] [default to undefined]
 **username** | **string** | Username. Not applicable for U4S websites. | [optional] [default to undefined]
 **client_id** | **number** | Client ID | [optional] [default to undefined]
 **order_id** | **number** | Order ID | [optional] [default to undefined]

package/docs/HostingWebsitesApi.md

@@ -7,12 +7,13 @@ All URIs are relative to *https://developers.hostinger.com*
 |[**createWebsiteV1**](#createwebsitev1) | **POST** /api/hosting/v1/websites | Create website|
 |[**deleteWebsiteV1**](#deletewebsitev1) | **DELETE** /api/hosting/v1/websites/{domain} | Delete website|
 |[**deployStaticSiteArchiveV1**](#deploystaticsitearchivev1) | **POST** /api/hosting/v1/accounts/{username}/websites/{domain}/deploy | Deploy static site archive|
+|[**listWebsiteSetupsV1**](#listwebsitesetupsv1) | **GET** /api/hosting/v1/onboardings | List website setups|
 |[**listWebsitesV1**](#listwebsitesv1) | **GET** /api/hosting/v1/websites | List websites|
 
 # **createWebsiteV1**
 > CommonSuccessEmptyResource createWebsiteV1(hostingV1WebsitesCreateWebsiteRequest)
 
-Create a new website for the authenticated client.  You must choose which hosting order to create this website on. Pass that order as `order_id` together with the domain name. List orders to see available IDs; the website is provisioned on that order\'s hosting plan.  The datacenter_code parameter is required when creating the first website on a new hosting plan - this will set up and configure new hosting account in the selected datacenter.  Subsequent websites will be hosted on the same datacenter automatically.  Website creation takes up to a few minutes to complete. Check the websites list endpoint to see when your new website becomes available.
+Create a new website for the authenticated client.  You must choose which hosting order to create this website on. Pass that order as `order_id` together with the domain name. List orders to see available IDs; the website is provisioned on that order\'s hosting plan.  The datacenter_code parameter is required when creating the first website on a new hosting plan - this will set up and configure new hosting account in the selected datacenter.  Subsequent websites will be hosted on the same datacenter automatically.  Website creation is asynchronous and takes up to a few minutes. Poll the list website setups endpoint with the `domain` filter every 10 to 15 seconds and wait for `status: completed` before uploading files, deploying or creating databases. While the setup is `running`, endpoints that operate on the website may respond with `404` or `409`. `is_enabled` on the websites list reflects suspension, not readiness.
 
 ### Example
 
@@ -169,6 +170,60 @@ const { status, data } = await apiInstance.deployStaticSiteArchiveV1(
  - **Accept**: application/json
 
 
+### HTTP response details
+| Status code | Description | Response headers |
+|-------------|-------------|------------------|
+|**200** | Success response |  -  |
+|**422** | Validation error response |  -  |
+|**401** | Unauthenticated response |  -  |
+|**500** | Error response |  -  |
+
+[[Back to top]](#) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to Model list]](../README.md#documentation-for-models) [[Back to README]](../README.md)
+
+# **listWebsiteSetupsV1**
+> Array<HostingV1OnboardingsOnboardingResource> listWebsiteSetupsV1()
+
+Returns the website setups started in the last 24 hours for the hosting accounts accessible to the authenticated client, newest first.  Meant for polling right after creating a website: the website shows up in the websites list before its server-side setup has finished, and while the setup is `running` endpoints that operate on that website may respond with `404` or `409`. Poll this endpoint with the `domain` filter every 10 to 15 seconds and wait for `status: completed` before uploading files, deploying or creating databases. `failed` means the setup stopped before finishing or has not reported progress for over an hour. Setups older than 24 hours are not listed.
+
+### Example
+
+```typescript
+import {
+    HostingWebsitesApi,
+    Configuration
+} from '@hostinger/sdk';
+
+const configuration = new Configuration();
+const apiInstance = new HostingWebsitesApi(configuration);
+
+let domain: string; //Filter by domain name (exact match) (optional) (default to undefined)
+
+const { status, data } = await apiInstance.listWebsiteSetupsV1(
+    domain
+);
+```
+
+### Parameters
+
+|Name | Type | Description  | Notes|
+|------------- | ------------- | ------------- | -------------|
+| **domain** | [**string**] | Filter by domain name (exact match) | (optional) defaults to undefined|
+
+
+### Return type
+
+**Array<HostingV1OnboardingsOnboardingResource>**
+
+### Authorization
+
+[apiToken](../README.md#apiToken)
+
+### HTTP request headers
+
+ - **Content-Type**: Not defined
+ - **Accept**: application/json
+
+
 ### HTTP response details
 | Status code | Description | Response headers |
 |-------------|-------------|------------------|
@@ -182,7 +237,7 @@ const { status, data } = await apiInstance.deployStaticSiteArchiveV1(
 # **listWebsitesV1**
 > HostingListWebsitesV1200Response listWebsitesV1()
 
-Retrieve a paginated list of websites (CloudLinux, Builder, and Horizons) accessible to the authenticated client.  This endpoint returns websites from your hosting accounts as well as websites from other client hosting accounts that have shared access with you.  Each website includes a `website_type` field describing the type of website detected on the underlying platform (`wordpress`, `builder`, `horizons`, `nodejs`, or `other`). Some fields, such as `vhost_type`, `username`, and `root_directory`, only apply to CloudLinux websites and are null for other platforms.  Use `website_types` to list only websites of a given detected type, e.g. only WordPress websites (`website_types=wordpress`) or only Node.js websites (`website_types=nodejs`). Combine with the other available query parameters to filter by username, order ID, enabled status, or domain name for more targeted results.
+Retrieve a paginated list of websites (CloudLinux, Builder, and Horizons) accessible to the authenticated client.  This endpoint returns websites from your hosting accounts as well as websites from other client hosting accounts that have shared access with you.  Each website includes a `website_type` field describing the type of website detected on the underlying platform (`wordpress`, `builder`, `horizons`, `nodejs`, or `other`). Some fields, such as `vhost_type`, `username`, and `root_directory`, only apply to CloudLinux websites and are null for other platforms.  Use `website_types` to list only websites of a given detected type, e.g. only WordPress websites (`website_types=wordpress`) or only Node.js websites (`website_types=nodejs`). Combine with the other available query parameters to filter by username, order ID, enabled status, or domain name for more targeted results.  A website appears in this list before its server-side setup has finished, and `is_enabled` reflects suspension, not readiness. To know when a newly created website is ready for file, deploy or database operations, poll the list website setups endpoint instead.
 
 ### Example
 

package/index.ts

@@ -3,7 +3,7 @@
 /**
  * Hostinger API
  *
- * API Version: 1.54.2
+ * API Version: 1.56.0
  *
  * NOTE: This file is auto-generated, DO NOT EDIT THIS FILE MANUALLY!
  * If you want to contribute or request a new feature, please create an issue or pull request on https://github.com/hostinger/api

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hostinger/sdk",
-  "version": "1.54.3",
+  "version": "1.56.0",
   "description": "Hostinger API TypeScript SDK",
   "author": "Hostinger",
   "repository": {