The update window

Each subscription carries an update expiry date. It is the mechanism behind “one year of updates included” and it governs downloads and nothing else.

How it is set#

At purchase, from the plan’s update days. A plan with 365 update days bought today expires a year from today.

How it moves#

• Renewal. A subscription.updated webhook from a successful renewal pushes it forward.
• Redeeming another code. Stacking a lifetime-deal code recalculates it from the new tier’s plan.
• Manually. You can edit it on the subscription — useful for a goodwill extension after a support problem.

What happens when it passes#

The customer keeps working software, keeps their license key, keeps every build they have already downloaded, and keeps their activated domains. Verification still returns "valid": true.

What changes is one field: update_entitled becomes false, and releases published after the expiry date are no longer downloadable.

Reading it from the API#

Verification returns both:

"update_entitled": true,
"update_access_until": "2027-03-14"

Good software uses both: refuse to install a newer build when update_entitled is false, and show the date so the customer knows what to renew and by when.

Release dates are the other half#

Entitlement compares the version’s release date against the update expiry. A customer whose window closed in March can still download anything released before March — including a bug-fix build you publish today, if you date it correctly. See Download gating.