Skip to main content

2 posts tagged with "sessions"

View All Tags

Permanently erase a session with a new flag on /session/delete

/session/delete can now permanently erase a session instead of only revoking it.

What's new​

  • hardDelete on POST /session/delete. Set to true to permanently delete a player session and its embedded consent, scoped to the calling product. Unlike the default revoke (which is internally retained), this physically removes the record and can't be undone.
  • Opt-in per developer. Available only to developers explicitly enabled for hard delete. Setting hardDelete: true without enablement returns FEATURE_DISABLED.
  • Every existing call is unaffected. Omitting hardDelete, or setting it to false, behaves exactly as /session/delete always has: a reversible revoke.
  • In-flight challenges are failed too. Any pending challenge tied to that exact session is set to FAIL, scoped to that session only (other sessions for the same player are untouched).

Documentation​

New Sessions and Permissions Guide and Documentation Updates

We've added a comprehensive guide for managing sessions and permissions, and updated our core concepts documentation with important clarifications.

What's New​

New Guide: Managing Sessions and Permissions​

We've added a new quick start guide: Managing sessions and permissions. This guide provides step-by-step instructions for:

  • Detecting permission changes using webhooks and session comparison
  • Handling session deletion and revocation
  • Communicating permission changes to players
  • Implementing permission upgrade flows
  • Understanding how challenges relate to sessions

This guide is essential for any integration that needs to respond to permission changes over time, such as when parents modify settings or players age up.

Documentation Updates​

Sessions Documentation​

The Sessions concept page has been updated with important clarifications:

  • Session ID persistence: Players have exactly one session per product. The session ID persists through permission changes, but a new session ID is created if a session is revoked and the consent flow is completed again.
  • Session deletion behavior: Deleted sessions return HTTP 400 with NOT_FOUND error code (not 404). This is intentional—deleted sessions should be treated as if they never existed.
  • Age-up changes: Age-up events don't trigger webhook notifications. You must use session comparison to detect these changes.

Permissions Documentation​

The Permissions concept page has been enhanced with:

  • managedBy field changes: Clarified that managedBy can change over time (for example, from GUARDIAN to PLAYER when a player ages up).
  • Player-managed permissions: When a player requests to enable a PLAYER-managed permission via the /session/upgrade API, it's automatically enabled without creating a challenge.
  • Permissions upgrade content: The permissions upgrade documentation has been merged into the Permissions page for better discoverability.

What Changed​

Merged Documentation​

  • The Permissions upgrade concept page has been merged into the Permissions page. All references have been updated to point to the new location.

Next Steps​

If you have any questions about these updates or need assistance with your integration, please don't hesitate to reach out to our support team.