📱Offline & Cache

DevPayr is designed to work reliably in the real world — not just in perfect network conditions.

Licensing systems that fail the moment a network blips are frustrating for users and dangerous for businesses. At the same time, systems that never revalidate become easy targets for abuse. DevPayr balances both by combining smart caching, offline tolerance, and explicit revalidation control.

This page explains how offline validation works, how caching is handled across SDKs, and how you stay in full control of when DevPayr should trust cache versus rechecking the API.

How DevPayr Handles Validation by Default

When your application boots using the DevPayr SDK, it performs a validation request against the DevPayr API. If that validation succeeds, the SDK stores the result locally as a cache.

From that point on:

• The cached result may be reused for subsequent validations

• This allows your app to keep running even if:

  • the user temporarily loses internet access

  • the DevPayr API is unreachable

  • the application restarts in an offline environment

This behavior is intentional. It prevents unnecessary downtime and avoids punishing legitimate users for transient network issues.

Importantly, only successful validations are cached. Failed or invalid checks are never treated as trusted cache.

What Is Cached?

The cache stores a validated snapshot of:

• license validity

The cache does not store secrets, API keys, or sensitive DevPayr credentials. It is only a short-lived representation of a successful validation state.

Each SDK handles storage in a way that makes sense for its environment (filesystem, memory, browser storage, etc.), but the behavior is consistent across platforms.

Offline Behavior

If your application cannot reach the DevPayr API during startup or validation:

• the SDK will attempt to use the last known valid cache

• if a valid cache exists, the app continues normally

• if no cache exists, validation fails and your configured invalidBehavior is applied

This means:

• first-time activation always requires internet

• subsequent runs can tolerate short-term offline usage

• users cannot activate new licenses offline

Offline mode is a convenience — not a loophole.

Revalidation Control (recheck)

While caching is enabled by default, DevPayr gives you explicit control over when cache should be ignored.

Every SDK supports the recheck option.

When recheck is enabled, the SDK will always bypass cache and make a fresh request to the DevPayr API.

This applies consistently across:

• Node.js SDK

• PHP SDK

• Python SDK

• Frontend SDK

Default Behavior

If recheck is not set (or set to false):

• the SDK may reuse cached validation

• API calls are minimized

• offline tolerance is enabled

This is recommended for normal runtime usage.

When recheck Is Set to True

When recheck is enabled:

• cached validation results are ignored

• the API is always contacted

• cache is refreshed only after a successful response

• offline validation is effectively disabled

If the API cannot be reached while recheck is enabled, validation will fail.

This behavior is strict by design.

When You Should Use recheck

You should enable recheck in situations where fresh truth matters more than resilience, such as:

• immediately after a successful payment

• first-time license activation

• license upgrades or downgrades

• domain or device changes

• admin dashboards

• compliance-sensitive environments

• security audits or enforcement checks

A common real-world pattern is:

• default mode for everyday app usage

• recheck = true for activation, billing, or account changes

This gives you both reliability and control.

Cache Is Not a Bypass

It’s important to understand what caching does not do.

• A revoked or expired license will fail on the next recheck

• A license tied to a different domain/device will fail revalidation

• Cached access does not grant permanent use

• Cache does not override server-side enforcement

Cache exists to smooth usage — not to weaken licensing.

SDK Consistency

The same caching and recheck rules apply everywhere:

• same behavior

• same guarantees

• same enforcement logic

The only difference is language syntax (true vs True), not meaning.

If recheck is enabled, the SDK always rechecks. If it is not enabled, cache may be reused responsibly.

There is no guessing and no hidden behavior.

Best Practices

• Allow caching for normal runtime checks

• Use recheck for critical or transactional flows

• Do not rely on offline mode for activation

• Treat cache as a temporary convenience, not a license grant

• Test both online and offline behavior in staging

Summary

• DevPayr caches successful validations by default

• Cache enables short-term offline resilience

• Offline mode is safe but controlled

• recheck forces live validation every time

• You decide when cache is acceptable

• DevPayr never silently weakens enforcement

Offline support exists to protect good users — not pirates.

⚠️ Important

Caching in DevPayr applies only to license validation during SDK bootstrap.

It does not affect:

• API Key requests

• Project, license, domain, or payment API calls

• Webhooks or server-side operations

Only the initial license validation performed during bootstrap is eligible for offline or cached reuse. All other DevPayr operations always require a live API request.