Clear boundaries for identity and Calendar access.

WonderNear identity

The current design uses Google identity data to link a person to a WonderNear account. The server-verified Google sub value is the stable identity. An email address is not used as the account identity or as proof of authorization.

If Google supplies a verified email and the API returns it, the App may show that email only as optional presentation information so a person can distinguish linked accounts.

Optional Calendar connection

Calendar connection is optional and separate from WonderNear identity. Read-only Calendar-list access is designed to show eligible destination Calendars owned by the connected user.

Owned-event write access is used only after the user selects an eligible WonderNear event, chooses a destination, reviews the action, and requests creation. WonderNear is not designed to create Calendar events autonomously.

Server-side storage and session safety

The authenticated API design keeps provider tokens, Google subjects, private Calendar identifiers, authorization codes, PKCE material, and encryption material away from this Website. Provider credentials and private Calendar bindings are designed to be stored server-side in encrypted records.

Short-lived access tokens stay in App memory. Rotating refresh tokens are designed for device-only platform secure storage. This page does not promise a retention period because none has been approved for publication.

Duplicate prevention and uncertain writes

Calendar creation uses a stable App retry key and a canonical event identity. A confirmed repeat converges on the existing event instead of intentionally creating another copy.

If a write result is uncertain, the App is designed to repeat the exact same request and retry key. It must not invent a new recovery route or a fresh key to bypass duplicate prevention.

Disconnect and deletion

The current API supports disconnecting a linked Google Calendar account. Its response distinguishes a disconnected WonderNear binding from whether provider revocation was confirmed. The App must relist bindings before retrying an unconfirmed disconnect.

The public API does not currently publish a complete WonderNear account-deletion operation or deletion timeline. See the truthful disconnect and data-deletion guidance; production publication remains blocked until an operator-approved request channel and process exist.

What this design does not do

• It does not expose a private Calendar publicly.
• It does not use email as the stable account identity.
• It does not let the client send arbitrary event content.
• It does not treat a browser redirect as proof of success.
• It does not create Calendar events without a user request.
• This Website does not use analytics, forms, cookies, or live APIs.