Update Profile
A user updates their personal details and app preferences.
Who Can Do This
Any user with status: active.
Steps
- Navigate to the profile section in the app.
- Update any of the following:
- Name, profile photo
- City, notification preferences, location sharing preference
- Save changes.
Rules
- Name and profile photo: fields supplied by the sign-in provider (Google or Apple) are read-only in 95octane and cannot be changed here. Only fields the user set themselves within 95octane are editable. If the user set a custom name or photo within 95octane (i.e. no provider value was available), those can be updated. A custom name must be 5 to 100 characters.
- Phone number: the phone number shown in profile is the number linked as the Mobile/OTP recovery provider. It is verified via OTP when set up and is not directly editable here. To change it, the user must update their Mobile/OTP provider via Add Authentication Provider. If no Mobile/OTP provider has been linked, the phone number field is empty and can be set by linking Mobile/OTP from profile settings or the account recovery page.
- City: first set during mandatory Onboarding. The profile section allows changing city after onboarding. The user's city scopes buddy search results — only riders in the same city appear. City is mandatory and cannot be unset once set. Changing city affects only future searches — existing buddy connections and pending buddy requests are unaffected. City changes are rate-limited to once every 1 month from the last change. The timer starts when the city is first set during onboarding — a new user cannot change their city for 1 month after account creation. The option to change city is unavailable until 1 month have elapsed since the last change date.
City change uses a two-step flow: 1. Detect — the app attempts GPS first, then falls back to IP address. The detected city is shown as a pre-selection. 2. Confirm — GPS permission is required to proceed. The user can confirm the detected city or select any other supported city from the list. If GPS permission is denied, the change cannot be confirmed. The user must grant GPS permission to proceed, or wait until the next allowed change period.
This two-step flow differs from onboarding: GPS permission is mandatory here (IP detection alone is not sufficient). If both GPS and IP fail, the city change cannot be completed — the user must grant location access and try again. - Notification preferences: notifications are grouped into categories — Buddy, Ride, Group, Subscription, Intercom, and Ban. Buddy, Ride, and Group have independent push and email toggles (all default to on). Subscription, Intercom, and Ban are in-app only with no configurable toggles. See Notification Reference for the full event catalog. - Email delivery: email notifications are only sent when the user has a verified email. Google always provides a verified email. Apple may not share an email (especially with the "Hide My Email" option) — in that case the account has no provider email and the user must complete the Verify Email flow to enable email notifications. - When a provider email exists (Google sign-in, or Apple when an email was shared): email toggles are enabled immediately — no verification step required. - When no provider email exists (Apple "Hide My Email" or similar): email toggles are displayed as disabled/greyed with a message indicating "email verification pending." They retain their stored values (default: on) while greyed — verifying an email makes them interactive without changing their values. A user who verifies an email will immediately receive email notifications if the toggles were at their default on state.
95octane shows a one-time in-app notice 30 days before the subscription expires — displayed the next time the user opens the app after the 30-day mark, once only. No push notifications or emails are sent for subscription status. Apple and Google handle store-side billing notifications independently.
- Location sharing: controls whether the user's real-time location is visible to other participants during an active ride. Location is never shared outside of a live ride session. Precise location permission is required to start navigation — if permission is not granted, the user cannot start a ride. For users riding at Essential tier (free users whose quota is exhausted, or expired subscribers), location sharing is always on and cannot be opted out — the toggle is disabled and displays a paid-feature indicator. The underlying preference value is preserved — if the user had set sharing to off before lapsing to Essential, that preference remains off and is re-applied automatically when they return to Premium. The user must change it manually if they want a different setting. The default for a user who has never set this preference (e.g. first-time subscriber) is on.
- Email: email management depends on how the account was created:
- Provider-set email (Google or Apple sign-in): the email comes from the sign-in provider and cannot be changed in-app. Users who signed in with Apple's "Hide My Email" option have a private relay address provisioned by Apple — this is also treated as a provider-set email and cannot be changed in-app. If a provider revokes or changes an email address, Firebase Authentication handles the update — 95octane reflects whatever Firebase Auth reports as the current provider email.
- No provider email: if the account has no provider-supplied email, the user can add one via the Verify Email flow. Once verified, a user-set email can be changed to a new address using the same flow. An account may hold multiple user-verified emails (for example, after two accounts are merged) — all are listed in profile settings and each receives product communications. The user can remove any of them, as long as at least one email remains on the account.
Known gap: Profile photos and custom display names have no content moderation at launch. Display names are also not unique — two riders can use the same name and photo, which creates an impersonation risk in buddy search and ride participation contexts. Photos are shown publicly across the app (ride lists, buddy previews, group lists) and names have only length validation (5–100 characters). Reporting, automated screening, and operator takedown tooling for abusive or inappropriate content will be considered post-launch once usage patterns are established.
Profile Visibility
In line with GDPR and India's DPDPA, identification data — email and phone number — is never part of the public profile. Other fields are either public by design (name, photo, city) or restricted by relationship. Visibility is evaluated live — removing a buddy connection immediately reverts the ex-buddy to seeing only the public profile. There is no cached view of buddy-only fields.
"Buddies only" means the viewer must have an accepted buddy connection with the user — the user's acceptance is required before any private fields are visible to the requester.
| Field | Public | Buddies only | User only |
|---|---|---|---|
| Name | ✓ | ||
| Profile photo | ✓ | ||
| City | ✓ (visible to any authenticated user; also used for buddy search scoping) | ||
| ✓ (never displayed to other users) | |||
| Phone (Mobile/OTP) | ✓ (never displayed to other users; can be used as a lookup key in buddy search only if the searcher already knows the number) |
What Happens Next
Changes are saved and reflected in the app immediately. When a name or profile photo is updated, the change propagates to all places where the user's information appears — ride participant lists, buddy previews, group member lists — via an asynchronous background process. Other users see the updated information shortly after the change is saved.
Failure Cases
- Email already in use: If the email address is already associated with another account, the update is rejected and the user is prompted to use a different email.
- Name too short or too long: If a custom name (not provider-supplied) is fewer than 5 or more than 100 characters, the update is rejected and the user is asked to choose a name within that range.
- City GPS denied or unavailable: The app can still detect a city via IP and show it to the user, but the change cannot be confirmed without GPS. The city change is abandoned — the previous city is retained and the app continues normally. The 1-month timer is not affected by an abandoned attempt — it only moves when a change is successfully confirmed.
- City change too soon: If fewer than 1 month have elapsed since the last city change, the option to change city is not available. The UI shows when the next change will be allowed.
- Photo upload failed: If the profile photo cannot be uploaded (for example, a network drop during upload), the photo is not changed. The previous photo is kept and the user can retry.
Status: partially-live. Name, photo upload/crop, and location sharing toggle are complete. Missing: city (field entirely absent from data model, API, and UI); per-category notification toggles (only a single global on/off exists — no Buddy/Ride/Group/Subscription/Intercom/Ban categories); phone/Mobile OTP management; name length validation (5–100 chars not enforced in frontend); Verify Email flow in settings; Essential-tier location sharing toggle enforcement.