Web Hosting
Last updated: June 22, 2026
Web Hosting is a resource that puts a built static website into a Space and serves it at a {subdomain}.weegloo.app address. Take a clothing store as an example: serving the built store site at dailywear-shop.weegloo.app is one Web Hosting.
The order of putting it up is as follows. First, bundle the build output as a ZIP or tar.gz and upload it through the Upload API to get one Upload. Then create a Web Hosting with POST /web-hostings, referencing that Upload. Once the system processes the uploaded files and sys.state becomes COMPLETED, you can reach the site at url. In CMA, a Web Hosting is a sub-resource of Space, and its path is based on /spaces/{spaceId}/web-hostings.
Resource structure
The following is the single-read response for the Web Hosting "DailyWear store site" after processing has finished. Along with sys (system properties), it has the body properties (name, description, isSpa, subdomain, url).
{
"sys": {
"id": "3trmXRM3RqbgSnifyg7PWeb01Examp",
"type": "WebHosting",
"space": { "sys": { "id": "tcq4V2Xb", "type": "Refer", "targetType": "Space" } },
"createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
"updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
"createdAt": "2026-06-18T11:40:00.000Z",
"updatedAt": "2026-06-18T11:40:05.000Z",
"state": "COMPLETED",
"totalFileSize": 245786,
"version": 3
},
"name": "DailyWear store site",
"description": "Static site for the clothing and accessories store",
"isSpa": true,
"subdomain": "dailywear-shop",
"url": "https://dailywear-shop.weegloo.app"
}Key properties:
subdomain: The subdomain the site will be served on. In the example above it isdailywear-shop, so the final address becomesdailywear-shop.weegloo.app.url: The site address you can reach once processing has finished.isSpa: Whether it is a single-page app (SPA). Iftrue, every path request is sent toindex.html.state: The deployment-processing state of the uploaded files. Explained in System properties (sys) below.
System properties (sys)
Every Web Hosting carries common system properties in the sys object. space, createdBy, and updatedBy are in the Refer shape ({ "sys": { "id", "type": "Refer", "targetType" } }).
| Property | Type | Description |
|---|---|---|
id | string | Unique resource identifier. It goes into {webHostingId} in the single-read, update, and delete paths. |
type | string | Resource kind. For a Web Hosting this is always "WebHosting". |
space | Refer<Space> | The Space this Web Hosting belongs to. |
createdBy | Refer<User> | The user who created it. |
createdAt | string (date-time) | Creation time. |
updatedBy | Refer<User> | The user who last updated it. |
updatedAt | string (date-time) | Last update time. |
state | string (enum) | Deployment-processing state. One of the four below. |
error | string | The reason when processing fails. Empty when there is no failure. |
totalFileSize | integer | The total size of the uploaded files (in bytes). |
version | integer (≥1) | Resource version. It increases by 1 with every create and update. This is the value you must send in x-weegloo-version on update and partial-update requests. |
state represents the processing stage of deploying the uploaded files. It is not a Content publish status, and a Web Hosting has no concept of publishing or archiving. Once the files are processed and it becomes COMPLETED, the site is reachable at url.
state | Meaning |
|---|---|
PENDING | Waiting to be processed. |
PROCESSING | Being processed. |
COMPLETED | Processing complete. Reachable at url. |
FAILED | Processing failed. The reason is held in sys.error. |
Body properties
The body properties of a Web Hosting are as follows.
| Property | Type | Description |
|---|---|---|
name | string (1-64) | The Web Hosting name. Required on create. |
description | string (≤128) | Description. Optional. |
isSpa | boolean | Whether it is a single-page app. If true, every path request is sent to index.html (for SPA routing). Required on create. |
subdomain | string (3-32) | The serving subdomain. Pattern ^[a-z0-9](?:[a-z0-9-]*[a-z0-9])?$ (lowercase letters, digits, hyphens; the first and last characters cannot be a hyphen). Required on create. |
upload | Refer<Upload> | A reference to the files to put up. It is a ZIP or tar.gz, must have index.html at the root, and assets must be referenced with relative paths. |
url | string | The access URL after processing finishes. Filled in by the system. |
fromPath | string | The base path for deployment. |
customDomain | string | The connected custom domain. Optional. Explained in Custom domain below. |
Checking a subdomain
Before creating a Web Hosting, you can check whether the subdomain you want to use is free. Pass the subdomain to check as the subdomain query on GET /web-hostings/availability?subdomain=....
The response has the following shape, and if available is true, you can use that subdomain.
{ "subdomain": "dailywear-shop", "available": true }Custom domain
Instead of the default address {subdomain}.weegloo.app, you can connect a domain you own to a Web Hosting. The state of the connected domain is represented by the customDomain object, in the { id, domain, dns, cert } shape. dns and cert are, respectively, the domain-ownership verification (DNS) and certificate-issuance (cert) states, and both are in the { status, txtName, txtContent } shape. txtName and txtContent are the name and value of the DNS TXT record you must register on the domain side.
{
"id": 1024,
"domain": "shop.dailywear.example",
"dns": {
"status": "PENDING",
"txtName": "_weegloo.shop.dailywear.example",
"txtContent": "weegloo-verify=3trmXRM3RqbgSnifyg7PWebVerifyEx"
},
"cert": {
"status": "PENDING",
"txtName": "_acme-challenge.shop.dailywear.example",
"txtContent": "acme-verify=3trmXRM3RqbgSnifyg7PWebCertEx"
}
}After registering the TXT records on the domain side, trigger verification with PUT /web-hostings/{webHostingId}/custom-domain/status/verify, and read the current state with GET /web-hostings/{webHostingId}/custom-domain/status. When verification finishes, dns.status and cert.status become VERIFIED. Calling the status read on a Web Hosting that has no connected custom domain responds with WGL404001.
API
The base URL for all endpoints below is https://cma.weegloo.com/v1, and a Bearer token that authenticates against CMA is required in the Authorization header. Update and partial update must also send the X-Weegloo-Version header (the current resource's sys.version) for optimistic concurrency control. Create and delete requests do not carry this header.
Related documents
- Upload API: The request that uploads a static-file ZIP to get an Upload to use when creating a Web Hosting.
- Space: The Space the Web Hosting belongs to.
