# Integration verification


Use an installed SDK and real sample operations. Read the language sample first; fixture values are not real customer credentials.

[Node](/en/samples/node/) · [Java](/en/samples/java/) · [C#](/en/samples/csharp/) · [Python](/en/samples/python/)

| Case | Expected result |
|---|---|
| Customer activation | start → customer login/approval → poll → valid result |
| Manual transport | request → portal import → activation.signox → apply on the same protected device |
| CSV permission | Write two rows only when valid AND demo_export is true; missing feature exits 3. |
| Tampering | Wrong product, request, signature or target cannot unlock the app. |
| Repeat request | Same request is idempotent; no second active device. |
| Replacement | Another target requires vendor approval tied to that request. |
| Explicit denial then disconnect | A protected client retains the signed denial and does not unlock from an old grant. |
| App branding | Login, signup, reset and separate request tabs keep the server-provided app identity. |

Record command, exit code, expected value, observed value and local evidence path. Pending approval, unavailable hardware and unexecuted checks are pending/not_run, never pass. Do not include license keys, tokens, private state or decrypted proofs in a report. The current physical offline revocation/rollback limits remain even if every software test passes.

[AI task prompt](/en/start/quickstart-ai/)