Build with Wareguard
Documentation
Wareguard issues access keys for your scripts and tells you, with one request, whether a key may be used. This page covers the concepts and the validation API.
Concepts
- Project
- Your workspace, for example a hub of scripts. A project holds services, contributors and the monetization provider accounts.
- Service
- One product inside a project, such as a single script. Each service has its own keys, settings, visitor page and analytics. Its Service ID is shown on the service overview.
- Access key
- A random
wg_…value that unlocks one service. Keys can expire, be revoked or banned, and can be bound to a device. - Checkpoint
- A step a visitor completes with a monetization provider (Linkvertise, LootLabs or Work.ink). Wareguard verifies each completion on its server; after the last checkpoint the visitor receives a key.
Validating keys
Send a POST request with the service ID, the key and, optionally,
a stable device identifier. No API token is needed.
https://wareguardv3.xyz/api/v1/key/validate Request body
| Field | Type | Description |
|---|---|---|
serviceId | UUID, required | The Service ID shown on the service overview. |
key | string, required | The access key to check. |
hwid | string, optional | A stable identifier for the device, up to 256 characters. Required when the service has HWID binding on. |
curl -X POST "https://wareguardv3.xyz/api/v1/key/validate" \
-H "Content-Type: application/json" \
-d '{"serviceId":"YOUR_SERVICE_ID","key":"wg_...","hwid":"DEVICE_ID"}'const response = await fetch("https://wareguardv3.xyz/api/v1/key/validate", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ serviceId, key, hwid })
});
const { data: [result] } = await response.json();
if (result.valid) {
// Grant access
} else {
console.log("Rejected:", result.reason);
}Response
A well-formed request always receives HTTP 200, whether or not the key is valid. Check valid, and use reason to explain
a rejection. A successful validation marks the key as used and, when HWID binding is on, binds
it to the first device that uses it. Malformed requests receive 400, and too many requests 429.
{
"success": true,
"message": "Key validation",
"data": [
{
"valid": true,
"reason": null,
"status": "USED",
"expiresAt": "2026-11-03T12:00:00.000Z"
}
]
}| Field | Type | Description |
|---|---|---|
valid | boolean | Whether the key may be used. |
reason | string or null | Why the key was rejected; null when it is valid. |
status | string or null | The key’s status, such as USED, EXPIRED or BANNED. |
expiresAt | string or null | When the key expires (ISO 8601); null if it never expires. |
Rejection reasons
| Reason | Meaning |
|---|---|
INVALID_KEY | The key does not exist, or belongs to another service. |
SERVICE_UNAVAILABLE | The service or its project is disabled. |
EXPIRED | The key has passed its expiry date. |
REVOKED | The key was revoked. |
BANNED | The key was banned. |
HWID_REQUIRED | HWID binding is on for the service and no hwid was sent. |
HWID_MISMATCH | The key is already bound to a different device. |
Rate limits
Visitor key pages
Every active service has a public page where visitors earn a key:
https://wareguardv3.xyz/visit/<project-slug>/<service-slug>
- 1 Visitors choose one of the service’s enabled options.
- 2 They complete its checkpoints with the provider.
- 3 Wareguard verifies every checkpoint on its server.
- 4 Once every checkpoint is verified, the page shows their key.
Configure provider credentials once per project, then add visitor options to each service.
Teams and permissions
- Project owners hold every permission.
- Contributors hold only what they are granted: project permissions such as managing contributors or monetization, and per-service access with its own permissions such as viewing, creating or revoking keys.
- A contributor with access to one service cannot see the others.
Ready to start?
Create a project, add a service and issue your first key.
