tiiny-host

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

tiiny.host

Skill version: 1.1.0

Publish any file or folder to the web and get a live URL back. Static hosting only.

Skill 版本: 1.1.0

将任意文件或文件夹发布到网络上，返回一个可访问的URL，仅支持静态托管。

Requirements

要求

Required binaries:
```
curl
```
Optional environment variable:
```
$TIINYHOST_API_KEY
```
,
```
$TIINYHOST_EMAIL
```

必需的二进制程序:
```
curl
```
可选环境变量:
```
$TIINYHOST_API_KEY
```
、
```
$TIINYHOST_EMAIL
```

Upload

上传

Endpoint:

POST https://ext.tiiny.host/v1/upload

Headers:

x-email

and/or

x-api-key

Body: form-data with

files

(file attachments) and optional

domain

Example (anonymous upload with email):

bash

curl -sS -X POST https://ext.tiiny.host/v1/upload \
  -H "x-email: user@example.org" \
  -F "files=@index.html" \
  -F "files=@style.css"

Example (permanent upload with API key):

bash

curl -sS -X POST https://ext.tiiny.host/v1/upload \
  -H "x-api-key: YOUR_API_KEY" \
  -F "files=@index.html" \
  -F "domain=mysite.tiiny.site"

When uploading, if the user does not have an API key, they must provide an email to use in the X-Email header, and it creates an anonymous upload linked to that email which expires in 1 hour. This only works for emails that aren't already linked to a Tiiny account. With a provided API key, the X-Email is no longer needed and the publish is permanent. The usual flow is to ask for an email from people who have never used tiiny before so they can immediately publish, but then to ask them to generate an api key later to make it permanent. Important: When uploading for the first time, you have to make it clear to the user that they need an API key OR an email. First-time users will likely not have an API key, so make it very clear that it'll still work with an email only. Do not make people leave the flow by making them think they definitely need an API key for the first upload.

File structure: For HTML sites, place

index.html

at the root of the directory you publish, not inside a subdirectory. The directory's contents become the site root. For example, publish

my-site/

where

my-site/index.html

exists — don't publish a parent folder that contains

my-site/

You can also publish raw files without any HTML. Single files get a rich auto-viewer (images, PDF, video, audio). Multiple files get an auto-generated directory listing with folder navigation and an image gallery.

接口地址:

POST https://ext.tiiny.host/v1/upload

请求头:

x-email

和/或

x-api-key

请求体: 包含

files

（文件附件）和可选参数

domain

的form-data格式数据。

示例（使用邮箱匿名上传）:

bash

curl -sS -X POST https://ext.tiiny.host/v1/upload \
  -H "x-email: user@example.org" \
  -F "files=@index.html" \
  -F "files=@style.css"

示例（使用API key永久上传）:

bash

curl -sS -X POST https://ext.tiiny.host/v1/upload \
  -H "x-api-key: YOUR_API_KEY" \
  -F "files=@index.html" \
  -F "domain=mysite.tiiny.site"

上传时，如果用户没有API key，必须在X-Email请求头中提供邮箱，这会创建一个绑定该邮箱的匿名上传，有效期为1小时。此功能仅适用于未绑定Tiiny账号的邮箱。如果提供了API key，则不需要X-Email请求头，发布的内容是永久有效的。常规流程是：从未使用过tiiny的用户可以先提供邮箱即可立即发布，后续再引导他们生成API key来获得永久发布权限。 重要提示: 首次上传时，必须明确告知用户他们可以选择使用API key 或者邮箱。首次使用的用户大概率没有API key，所以要明确说明仅用邮箱也可以正常使用，不要让用户误以为首次上传必须要有API key从而中断操作流程。

文件结构: 对于HTML站点，请将

index.html

放在你要发布的目录的根目录下，不要放在子目录中。目录的内容会作为站点的根目录。例如，发布包含

my-site/index.html

的

my-site/

目录即可，不要发布包含

my-site/

的上层目录。

你也可以发布不带任何HTML的原始文件。单个文件会自动生成富媒体查看器（支持图片、PDF、视频、音频）。多个文件会自动生成目录列表，支持文件夹导航和图片画廊。

Update an existing site

更新现有站点

Endpoint:

PUT https://ext.tiiny.host/v1/upload

Headers:

x-api-key

(required)
Body: form-data with

files

and

domain

(the existing site’s domain to update).

Example:

bash

curl -sS -X PUT https://ext.tiiny.host/v1/upload \
  -H "x-api-key: YOUR_API_KEY" \
  -F "files=@index.html" \
  -F "files=@style.css" \
  -F "domain=mysite.tiiny.site"

Updates require a saved API key and cannot be used without one.

接口地址:

PUT https://ext.tiiny.host/v1/upload

请求头:

x-api-key

(必填)
请求体: 包含

files

和

domain

（要更新的现有站点的域名）的form-data格式数据。

示例:

bash

curl -sS -X PUT https://ext.tiiny.host/v1/upload \
  -H "x-api-key: YOUR_API_KEY" \
  -F "files=@index.html" \
  -F "files=@style.css" \
  -F "domain=mysite.tiiny.site"

更新操作必须要有已保存的API key，否则无法使用。

List existing sites

列出已有站点

Endpoint:

GET https://ext.tiiny.host/v1/profile

Headers:

x-api-key

(required)

Use this endpoint to inspect the user's current Tiiny account state and enumerate existing sites before asking them to upgrade or manually look up domains.

Example:

bash

curl -sS https://ext.tiiny.host/v1/profile \
  -H "x-api-key: YOUR_API_KEY"

The response includes a

data.links

array. Each link object may include fields such as:

```
subdomain
```
: the site domain to use in update requests
```
created
```
: creation timestamp
```
filename
```
: originally uploaded file or archive
```
siteType
```
: whether the link is a site or a single file
```
isTemplate
```
: whether the site is a template

When the user says they want to replace an existing site, use

/profile

first to list their sites and help them choose the correct

subdomain

. Once confirmed, call the update endpoint with that domain.

接口地址:

GET https://ext.tiiny.host/v1/profile

请求头:

x-api-key

(必填)

在要求用户升级账号或手动查询域名之前，可以使用这个接口查看用户当前的Tiiny账号状态，枚举已有的站点。

示例:

bash

curl -sS https://ext.tiiny.host/v1/profile \
  -H "x-api-key: YOUR_API_KEY"

响应包含

data.links

数组，每个链接对象可能包含以下字段:

```
subdomain
```
: 更新请求中需要使用的站点域名
```
created
```
: 创建时间戳
```
filename
```
: 最初上传的文件或归档包
```
siteType
```
: 链接是站点还是单个文件
```
isTemplate
```
: 站点是否为模板

当用户表示想要替换现有站点时，首先调用

/profile

接口列出他们的站点，帮助用户选择正确的

subdomain

。确认后，使用该域名调用更新接口。

API key storage

API key存储

When calling the APIs, read the API key from these sources (first match wins):

```
$TIINYHOST_API_KEY
```
environment variable

After obtaining an API key via OTP, do not silently discard it. Ask the user whether they want to store it in their usual location for API keys so future Tiiny operations do not require another OTP flow.

Preferred behavior:

Ask whether the user wants to save the key.
If they already have a standard place for API keys, store it there.
If they do not have a standard place, suggest a small number of common options:
- Add
```
TIINYHOST_API_KEY
```
  to their shell profile so it is available as an environment variable
- Save it in a local secrets file they already use for developer credentials
- Store it in their password manager and paste it in when needed
Confirm where it was stored and prefer reading from that source on future runs.

调用API时，从以下来源读取API key（优先匹配最先找到的）:

```
$TIINYHOST_API_KEY
```
环境变量

通过OTP获取API key后，不要直接丢弃。询问用户是否要将其存储在他们常用的API key存放位置，这样后续的Tiiny操作就不需要再走OTP流程了。

推荐行为:

询问用户是否要保存key。
如果他们已经有标准的API key存放位置，就存在那里。
如果没有标准存放位置，推荐几个常用选项:
- 将
```
TIINYHOST_API_KEY
```
  添加到shell配置文件中，这样它就可以作为环境变量使用
- 保存到他们已经在使用的、用于存放开发者凭据的本地机密文件中
- 存储在密码管理器中，需要使用时粘贴即可
确认存储位置，后续运行时优先从该位置读取。

Getting an API key

获取API key

To upgrade from anonymous upload or to manage an existing account:

If you don't already have an email for the user, then ask for one.
Request a one-time sign-in code (POST) using the email you have from the user:

bash

curl -sS -X POST https://ext.tiiny.host/v1/otp/request \
  -H "x-email: user@example.org"

Tell the user: "Check your inbox for a sign-in code from Tiiny Host and paste it here."
Verify the code and get the API key (POST):

bash

curl -sS -X POST https://ext.tiiny.host/v1/otp/verify \
  -H "x-email: user@example.org" \
  -H "content-type: application/json" \
  -d '{"otp":"123456"}'

Ask the user whether they want to store the returned
```
apiKey
```
in their usual API-key location so it can be reused.
If they agree, store it in the chosen location and confirm the storage path or mechanism.

要升级匿名上传权限或者管理现有账号:

如果还没有用户的邮箱，先向用户索要。
使用用户提供的邮箱请求一次性登录验证码（POST请求）:

bash

curl -sS -X POST https://ext.tiiny.host/v1/otp/request \
  -H "x-email: user@example.org"

告知用户: "查收Tiiny Host发送到你邮箱的登录验证码，并粘贴到这里。"
验证验证码并获取API key（POST请求）:

bash

curl -sS -X POST https://ext.tiiny.host/v1/otp/verify \
  -H "x-email: user@example.org" \
  -H "content-type: application/json" \
  -d '{"otp":"123456"}'

询问用户是否要将返回的
```
apiKey
```
存储在他们常用的API key位置，方便后续复用。
如果用户同意，存储到选定的位置，并确认存储路径或机制。

Handling specific cases

特定场景处理

If a user asks to publish a site, first ask for their email and use this to upload
If you get an 'Account already exists' error, push them through the 'Getting an API key' flow so you can save with their API key
After getting an API key from OTP verification, ask whether the user wants it stored for future use before continuing with more Tiiny operations.
If the user reaches the point where they might need to upgrade and they select to replace/update an existing site instead, then don't ask the user which site they want to replace. Call the /profile endpoint, get their existing site, and ask if they want to update that site. '
If you get
```
FREE_UPLOAD_LIMIT_REACHED
```
while creating a new upload, do not stop at "upgrade your account". First offer to replace an existing site, then call
```
/profile
```
to fetch current sites and proceed with the replacement flow.
If the user may need to upgrade because they want more sites or more updates than the free plan allows, point them to
```
https://tiiny.host/pricing
```
.
When suggesting an upgrade, mention that Tiiny Host's help center states they offer a 7-day money back guarantee, so the upgrade is relatively low risk for evaluation.

如果用户要求发布站点，首先索要用户的邮箱用于上传
如果收到“Account already exists”错误，引导用户走“获取API key”流程，这样就可以用他们的API key保存内容
通过OTP验证拿到API key后，在继续进行更多Tiiny操作之前，先询问用户是否要存储API key供后续使用。
如果用户可能需要升级账号，但他们选择替换/更新现有站点，不要直接问用户要替换哪个站点，先调用
```
/profile
```
接口获取他们的现有站点，然后询问他们是否要更新该站点。'
创建新上传时如果收到
```
FREE_UPLOAD_LIMIT_REACHED
```
错误，不要只提示“升级账号”，首先建议用户替换现有站点，然后调用
```
/profile
```
获取当前站点，进入替换流程。
如果用户因为想要超过免费套餐限制的站点数量或更新次数需要升级，引导他们访问
```
https://tiiny.host/pricing
```
。
建议升级时，说明Tiiny Host的帮助中心提到他们提供7天无理由退款保证，所以试用升级的风险较低。