---
slug: "/docs/v1/integration-guide/test"
title: "Test the complete lifecycle"
description: "Stage 13: test the complete lifecycle with a clear outcome, verification steps and one next action."
section: "Integration Guide"
order: 28
audience: "all"
level: "intermediate"
last_updated: "2026-10-20"
version: "v1"
related: []
draft: false
layout: "guide"
---
## What you will do
Exercise negative cases before [customers](/docs/v1/start/glossary#customer) rely on your integration.
Use [Sandbox](/docs/v1/start/glossary#sandbox) only. This is a checklist for your implementation, not permission to test attacks on other systems.
1. Run the Stage 7 file with activate. Confirm one active [device](/docs/v1/start/glossary#device).
2. Run validate, then check after restarting the process. Confirm the same identity/seat.
3. Activate on a second private state directory. With Max devices 2, a third installation must return MAX_DEVICES_REACHED.
4. Run deactivate on one installation. A replacement [activation](/docs/v1/start/glossary#activation) should now fit.
5. In **[Licenses](/docs/v1/start/glossary#license) → Manage**, choose Suspend. A forced online validate must deny. Restore allows a new activation; it does not revive the old revoked token. Run activate again before expecting validation to succeed.
6. Create a separate test license, choose Revoke and verify denial. Revocation is not a temporary support toggle.
7. Test a short-duration/expired license. Do not alter the server clock or production database to fake this result.
8. Test supported renewal through the documented backend/store workflow, with a confirmed paid period; it must not duplicate the license. Renew extends the license, not the token's original lifetime. Validate online to obtain the updated signed decision; activate again if the existing token has expired or was revoked.
9. Disconnect the network; test valid, missing, corrupted and expired cache states.
10. Modify a signed payload in an isolated verifier test. The verifier must deny it.
11. Test wrong email, App ID and environment. Cross-environment access must fail.
12. Follow your selected store's duplicate, failure, cancellation and refund checklist.
:::tabs
:::tab python Python
Use the exact same file and state directory for a lifecycle:
```bash
.venv/bin/python license-check.py activate
.venv/bin/python license-check.py validate
.venv/bin/python license-check.py check
.venv/bin/python license-check.py deactivate
```
Activation/validation success prints Sandbox license verified.; deactivation prints Device released. A failure exits nonzero and must not unlock your software.
:::
:::tab javascript JavaScript / Node.js
Use the exact same file and state directory for a lifecycle:
```bash
node license-check.mjs activate
node license-check.mjs validate
node license-check.mjs check
node license-check.mjs deactivate
```
Activation/validation success prints Sandbox license verified.; deactivation prints Device released. A failure exits nonzero and must not unlock your software.
:::
:::tab php PHP
Use the exact same file and state directory for a lifecycle:
```bash
php license-check.php activate
php license-check.php validate
php license-check.php check
php license-check.php deactivate
```
Activation/validation success prints Sandbox license verified.; deactivation prints Device released. A failure exits nonzero and must not unlock your software.
:::
:::tab csharp C# / .NET
Use the exact same file and state directory for a lifecycle:
```bash
dotnet run --project Guide.csproj -- activate
dotnet run --project Guide.csproj -- validate
dotnet run --project Guide.csproj -- check
dotnet run --project Guide.csproj -- deactivate
```
Activation/validation success prints Sandbox license verified.; deactivation prints Device released. A failure exits nonzero and must not unlock your software.
:::
:::tab curl cURL / other language
Use the same activate → validate → deactivate sequence in your real REST client project and its signature verifier. Exercise every negative case above; a cURL HTTP response alone is not a passing access check.
Use the selected language SDK or REST client from [SDKs and languages](/docs/v1/sdks/overview), its [signature verifier](/docs/v1/security/verify-ed25519), and the supported [webhook verifier](/docs/v1/guides/verify-webhook-signatures).
:::
:::

## Expected result
Your test notes show both successful access and deliberate denials, without real charges or leaked tokens.
## If it does not work
Stop at the first unsafe result. Keep the application locked, record a safe [request ID](/docs/v1/start/glossary#request-id) and contact support. Do not “fix” a negative test by removing its signature or entitlement guard.
## Stage checklist
- All lifecycle, device, state, network and signature cases pass for my runtime.
- I tested the non-programmer [delivery](/docs/v1/start/glossary#delivery) route if I use one.

## Next steps
[Continue to Stage 14: Go live safely](/docs/v1/integration-guide/go-live)