---
order: 8
slug: "/docs/v1/start/go-live-checklist"
title: "Go live checklist"
section: "Start here"
description: "Review credentials, signed decisions, failure handling, offline behaviour, webhook operations, monitoring and customer support before Live licensing."
audience: "all"
level: "beginner"
last_updated: "2026-10-17"
version: "v1"
related: ["/docs/v1/start/quickstart","/docs/v1/start/glossary"]
draft: false
---
Move to [Live](/docs/v1/start/glossary#live) only after the actual application, its failure paths and its support process have been tested.

## What you will learn
- Review production readiness without confusing it with a successful demo.
- Plan safe credentials, [customer](/docs/v1/start/glossary#customer) support and operations.
- Identify known defects or missing operational evidence that block your own release.

## Prerequisites
- Complete the [Sandbox quickstart](/docs/v1/start/quickstart).
- Read [integration limitations](/docs/v1/integration-notes).
- Have eligible paid Live access and control of your application's release process.

## Credentials and environment
1. Confirm the paid platform entitlement and Live availability in Billing.
2. Issue Live customer [licenses](/docs/v1/start/glossary#license) deliberately; do not reuse Sandbox records.
3. Create separate minimum-scope Live server keys only where management is needed.
4. Put [public App ID](/docs/v1/start/glossary#public-app-id) and explicit LIVE selection in the app configuration.
5. Remove Sandbox sample keys, debug dumps and [developer API keys](/docs/v1/start/glossary#developer-api-key) from distributed artifacts.
6. Rehearse immediate key replacement and revocation without assuming an overlap window.
Detail: [environments](/docs/v1/start/environments) and [authentication](/docs/v1/start/authentication#create-a-key).
Expected result: each credential has an owner and a specific [product](/docs/v1/start/glossary#product), environment and consumer.

## Signed decisions and application enforcement
1. Require valid or Valid before every [feature](/docs/v1/start/glossary#feature) decision.
2. Test a real signed response for your product metadata, numeric features and customer text.
3. Test persisted cache round trips in the actual SDK release.
4. Verify product, environment and installation binding, expiry and signed deadlines.
5. Keep protected server actions authorized on your backend.
6. Record a signing-key rollout plan if you pin a [public verification key](/docs/v1/start/glossary#public-verification-key).
Detail: [activation flow](/docs/v1/start/activation-validation-deactivation) and [signature/cache limitations](/docs/v1/integration-notes).
Expected result: tampered, wrong-installation and invalid license results do not unlock access.
Known JavaScript integral-float and C# cache limitations remain release risks. Do not mark this checklist passed merely because the narrow demonstration data works.

## Failure paths and end-user UX
1. Test invalid key, wrong supplied email, wrong environment and installation mismatch.
2. Test [device](/docs/v1/start/glossary#device) exhaustion and cumulative activation exhaustion separately.
3. Test expired, suspended and revoked licenses.
4. Test timeout, unavailable server, missing cache, expired grace and clock rollback.
5. Test deactivation and a deliberate reinstall/transfer.
6. Use plain messages that say what the customer can do without inventing a payment cause.
Detail: [flow outcomes](/docs/v1/start/activation-validation-deactivation) and [lifecycle](/docs/v1/start/license-lifecycle).
Expected result: users can retry a network problem or contact the publisher; confirmed invalidation does not receive outage fallback.

## Offline policy and storage
1. Choose [validation interval](/docs/v1/start/glossary#validation-interval) and [offline grace](/docs/v1/start/glossary#offline-grace) appropriate to your risk.
2. Explain offline deadlines to your customers before purchase.
3. Test the actual packaged app on Windows, macOS and Linux versions you support.
4. Review token storage, file permissions and optional keyring behaviour.
5. Decide recovery behaviour for lost or copied application state.
Detail: [offline flow](/docs/v1/start/activation-validation-deactivation#offline-or-timeout) and [local state](/docs/v1/start/activation-validation-deactivation#local-state-and-os-differences).
Expected result: bounded offline access works as intended without claiming instantaneous disconnected revocation.

## Webhook operations
1. Use an HTTPS endpoint on your backend with the correct environment.
2. Store its signing secret privately and verify signatures and timestamp tolerance.
3. Deduplicate repeated event handling and tolerate ordering differences.
4. Monitor [delivery](/docs/v1/start/glossary#delivery) failures and exhausted retries.
5. Rehearse secret replacement; current queued attempts use the current endpoint secret.
Detail: [webhook summary](/docs/v1/start/core-concepts#record-reference) and [current operational limitations](/docs/v1/integration-notes).
Expected result: missing webhooks do not determine whether a license is valid. Follow the complete event/security reference when it is published; this checklist is not a replacement verifier implementation.

## Monitoring, limits and backup responsibility
1. Monitor API and audit logs, [request IDs](/docs/v1/start/glossary#request-id) and webhook delivery history.
2. Review plan creation limits and current usage before a sales launch.
3. Check [platform status](/status) and handle unavailable network requests in your app.
4. Protect backup copies of your own server credentials under your recovery policy; never ask customers to back up KDPika private signing keys.
5. Preserve nonsecret mappings between your orders, customers and issued license IDs.
6. Confirm scheduler, backup and restore operations for systems you operate rather than assuming an untested RPO or RTO.
Detail: [platform versus product capacity](/docs/v1/start/core-concepts#product-and-platform-plans) and [network outcomes](/docs/v1/start/activation-validation-deactivation#offline-or-timeout).
Expected result: operational failures can be diagnosed without exposing secrets. The same-host status page is not an independent monitor or an SLA.

## Sales, privacy and customer support
1. Confirm purchases in your own backend before issuing software licenses.
2. Document your refund, renewal, transfer and lost-key policies.
3. Give customers a publisher support channel and a recovery procedure.
4. Minimise customer information sent into metadata and labels.
5. Review your privacy notice, retention and the platform's processing terms.
6. Confirm the remaining hosting/provider/legal facts relevant to your own obligations.
Detail: [sales boundaries](/docs/v1/start/introduction#what-the-service-does-not-do), [use cases](/docs/v1/start/use-cases), [privacy](/legal/privacy) and [DPA](/legal/dpa).
Expected result: software buyers know whom to contact; KDPika platform billing is not confused with your product sales.

## Expected result
Each applicable check has an actual test or operational owner. Unresolved security/compatibility risks are documented and addressed before your application is declared production-ready.

## Common mistakes
- Checking only a successful activation on one development machine.
- Assuming a demo certifies every OS credential backend.
- Treating an advisory monthly API allowance as a hard block.
- Claiming compliance, response-time guarantees or uptime without confirmed evidence.

## Security notes
Do not disable verification to pass a release test. Fully controlled customer machines can patch local code. No checklist is an independent security audit or universal legal certification.

## Troubleshooting
| Symptom | Cause | Fix |
| --- | --- | --- |
| A required test fails | Application or SDK is not ready for that case | Stop release for the affected path; investigate rather than bypassing it |
| Ownership of an operational check is unclear | No documented support/recovery process | Assign an owner and record the procedure |
| Need a capability not documented as supported | Product assumptions exceed actual behaviour | Ask support before committing to customers |

## Next steps
Review [use-case trade-offs](/docs/v1/start/use-cases) and resolve any blocked check with your engineering and support owners.

## Related
- [Quickstart](/docs/v1/start/quickstart)
- [Authentication](/docs/v1/start/authentication)
- [Current integration limitations](/docs/v1/integration-notes)