Net Results Privacy

Last updated: September 19, 2026

Net Results is a companion app for USTA NorCal league players. This policy describes the information the app handles, where it is stored, and when it is sent to the Net Results service or another service.

Account sign-in and sessions

When you sign in, your USTA NorCal or UTR Sports login identifier and password are sent over HTTPS to the Net Results API, which forwards them to the selected service to establish a session. Net Results does not persist those credentials on its servers.

If you enable Face ID for an account, that account's login identifier and password are stored in the device's protected, device-only Keychain and require the enrolled Face ID to read. Turning off Face ID for that account deletes the saved credentials.

After a successful USTA sign-in, the USTA session cookie and the Net Results account token used for protected changes such as venue-rating and lineup edits are stored in the device Keychain. The verified USTA player ID, player name, and login identifier are stored in the app's local preferences so the session can be restored. Signing out of USTA removes that session information, but it does not remove separately saved Face ID credentials.

Account tokens contain the USTA player ID, issue and expiration times, and a schema version. They are signed by the Net Results server, expire after 90 days, and require a new USTA sign-in when expired or unverifiable.

After a successful UTR sign-in, UTR session cookies, the account's claimed player ID and rating-precision access, and a signed proof of that access are stored in the device Keychain and sent to the Net Results API when a UTR lookup is needed. Signing out of UTR removes that session information. Signing out of USTA leaves the UTR session in place. The next time you sign in to USTA, Net Results uses the USTA player's name, location, and, when needed, recent teammates to find the corresponding UTR profile. The UTR session remains in place if that profile belongs to the signed-in UTR account; otherwise, the app signs out of UTR. Separately saved Face ID credentials for both accounts remain until Face ID is turned off for the corresponding account.

Tennis data and app features

The Net Results API retrieves and processes the information needed for the features you request. Depending on the feature, this can include player and team IDs, names, locations, ratings, schedules, rosters, match results, scorecards, lineups, availability, venue details, captain or co-captain contact information, and roster-player phone numbers available to a signed-in team captain or co-captain. Availability, lineup assignments, pre-match notes, lineup visibility, and scorecard changes are sent through the Net Results API to USTA NorCal.

Player or team search text is sent to the Net Results API and USTA NorCal to perform the search. The app's on-device response cache can retain the search text as part of its cache key along with the returned results. First-party analytics records only the query length and result counts, as described below.

Net Results obtains tennis data from USTA NorCal, UTR Sports, and TennisRecord.com. For a UTR rating lookup, the API may send a player's USTA-listed location to Apple Maps Server API to obtain coordinates, then send the player's name, location, and those coordinates to UTR Sports along with the UTR session cookies needed to authorize the request. TennisRecord lookups may use a player's name, location, and team names to identify the appropriate public record.

When you request weather for an eligible upcoming match, the API sends the canonical USTA venue address to Apple Maps Server API to obtain coordinates, then sends those coordinates and the forecast hour to Apple WeatherKit. Venue coordinates can remain in the shared Valkey cache for up to 30 days, and forecast responses are cached until they are no longer useful for the match.

The API keeps derived response data in a shared Valkey cache to make the app faster and reduce requests to those services. UTR ratings are separated by rating-precision access and are cached for 24 hours. Confirmed USTA-to-UTR identity matches and unresolved identity-review records can be retained for up to 90 days. TennisRecord ratings have a 14-day logical cache lifetime and are normally refreshed sooner when background checks detect an update. Depending on the other data, the logical cache lifetime is 10 minutes, 1 hour, or 24 hours; expired non-UTR entries may remain available for refresh for up to another 24 hours. A player's USTA-listed location and its geocoded coordinates can also remain in an in-memory server cache for up to seven days.

The API also keeps aggregate TennisRecord cache-access counts by USTA player ID for up to 30 days. These counts are not associated with the requesting account or device and are used only to prioritize background cache refreshes.

When automated matching cannot determine one UTR profile for a USTA player, Net Results sends the administrator a daily email through Resend at 04:00 UTC listing the pending manual reviews. Each listing includes the player's USTA player ID, name, USTA-listed location, and USTA profile link; candidate UTR profile identifiers, names, locations, and teammate-overlap counts; sanitized UTR request links; and the review timestamp. Session cookies, passwords, and authorization headers are not included. Pending matches can remain in later daily emails until an administrator records a mapping or the cached review expires, up to 90 days. Resend processes the email content to deliver the operator notice.

Private lineup-editor forms, pre-match notes, lineup-visibility settings, submitted lineup payloads, and roster-player phone numbers are not placed in the shared response cache. Roster-player phone numbers are returned only after the Net Results API verifies that the signed-in account is the team's captain or co-captain. The response is not stored in the app's on-device API cache or included in issue-report network traces, and the app holds it only while the team view remains open.

When an official lineup is not available or is hidden, you can choose “I'm playing” for that match. Net Results stores your USTA player ID, the team and match IDs, and creation and update times in Elasticsearch so the match can appear as one you are playing on your team and player views. This indication is private to your signed-in account and is not sent to USTA NorCal. A visible official lineup always takes precedence: Net Results removes the indication when that lineup is read or published. The API also checks these records once a day and removes indications for matches that have a result or scorecard.

For teams with practices enabled, captains and co-captains can schedule a practice with its date and time, time zone, venue name and address, optional court text, and player capacity. Net Results stores those details, the team and creator identifiers, player sign-ups, and change history in Elasticsearch. Signed-in roster players can see the names of teammates who signed up. Practice data is not sent to USTA NorCal. While a captain enters a venue, the app sends the typed venue or address text directly to Apple's MapKit search service to provide suggestions; Net Results does not store suggestion queries unless the captain saves one as the practice venue.

Notifications

If you allow notifications after signing in, Net Results registers a random installation identifier and the device's Apple Push Notification service (APNs) token with the Net Results API. The API associates them with your USTA player ID and stores your separate availability-reminder and upcoming-match-reminder preferences, including the practice-notification preference. The installation identifier is also kept in the device Keychain.

To plan reminders, the API uses public player profiles and team schedules. It stores the team and match identifiers and display details, scheduled delivery time, delivery state, attempt count, APNs response reason, and timestamps needed to reconcile schedule changes and prevent duplicate delivery. It does not fetch or store your USTA availability response, lineup membership, USTA session, or credentials for this purpose. APNs tokens are stored in Elasticsearch but are not indexed or written to application logs or issue-report network traces.

When you are signed in, Net Results also stores reminder notifications, product updates, maintenance notices, and service-status messages in an account-specific Notification Center. Each item includes your USTA player ID, its title and message text, category, creation and expiration times, read time, and any player, team, match, or practice routing identifiers needed to open the relevant screen. The app keeps a local cached copy of recent items for offline display. Marking an item as read, including by opening its push notification, updates the server copy so read state can stay consistent across your devices. The API also retains a timestamp indicating that it created the one-time Notification Center welcome message for your account, so that discovery message is not recreated after its six-month history record expires.

Net Results sends Apple the APNs token, notification text, and the player, team, match, or practice routing identifiers needed to open the relevant screen. Practice notifications can also include a teammate's name and the number of remaining spaces when someone joins or withdraws. Apple processes this information to deliver the notification. Depending on your iOS settings, notification text may appear on the Lock Screen or other system surfaces. You can turn each reminder type off in Net Results Settings or change all notification access in iOS Settings. Net Results does not send practice notifications by SMS.

Venue ratings

When you submit a match-venue rating, Net Results stores:

Your public attribution is your first name and last initial by default. If you enable “Show only my initials,” only your first and last initials are shown. Your player ID is not returned in the public ratings API. Other players can see the public attribution, rating values, match ID, and creation and update times. You can see your own written review while it is pending or rejected, but other players cannot see it until an administrator approves it. Rejected text remains in your rating so you can revise it. New or edited written reviews return to pending review; removing the text removes it from the rating.

Once a day, Net Results sends the administrator an email through Resend listing all pending written reviews. Each listing includes the submitted and calculated rating information, reviewer and venue details, timestamps, and the internal review and version identifiers needed to review one item safely. Resend processes this email content to deliver the moderation notice. Pending reviews remain in later daily notices until approved, rejected, or removed. Venue ratings are stored in Elasticsearch by the Net Results backend and are used to provide venue feedback; they are not used for cross-app tracking.

Product analytics

Release builds on physical devices send first-party product analytics through the Net Results API to Elasticsearch. Debug and simulator builds do not send this telemetry. Analytics includes event time, app version and build, subscription mode, pseudonymous feature interactions, selected app settings, aggregate search and lineup-planner counts, ad or purchase event outcomes, and a random session ID with session duration. A separate random analytics installation identifier is included only when a session starts so Net Results can count unique active installations over time. It is stored in the app's ordinary on-device storage, is not associated with USTA or UTR accounts or the notification installation identifier, and normally resets when the app is deleted. The session ID correlates activity only within one app activation and is not reused as an account or device identity.

First-party analytics does not include USTA or UTR account identifiers, login identifiers, names, email addresses, search text, player or profile identities, selected-result identities, team or match identifiers or names, or precise device or player location. When a session starts, the API may use the request IP address to derive an approximate city, region, and country for aggregate active-installation reporting. The IP address is discarded and is never stored in analytics. The API accepts telemetry only through an event and property allowlist and discards unknown fields sent by older app releases before writing an analytics document. The analytics installation identifier is not sent to Google Mobile Ads or combined with data from other companies. First-party analytics are not used for tracking across other companies' apps or websites.

Ads and subscriptions

On each launch on a physical device, Net Results first uses Apple's StoreKit to resolve whether the ad-free subscription is active. Only after StoreKit verifies an ad-supported session does Net Results use Google's User Messaging Platform to refresh the privacy requirements that apply before initializing the Google Mobile Ads SDK or requesting an ad. Where required, Google presents privacy choices. You can revisit those choices from Privacy Choices in the Ads section of Net Results Settings whenever Google requires that option to be available. For a verified ad-free session, Net Results does not initialize the Google Mobile Ads SDK or request ads.

Google may process IP address and estimated general location, device or advertising identifiers, ads shown, ad and app interactions, crash logs, and performance data as part of providing, measuring, and protecting ads. Net Results requests personalized ads only when the applicable Google consent choices allow personalization and iOS tracking authorization has been granted. Otherwise, every request is explicitly configured for non-personalized treatment; Google may further restrict it to limited ads based on your consent signals. No ad request is sent while privacy choices are unresolved. If a privacy update or form fails, Net Results requests only non-personalized ads when Google's previously stored consent state permits an ad request, and sends no ad request otherwise. Net Results does not send venue ratings to Google. If a purchase, restore, or transaction update verifies an active ad-free subscription, Net Results cancels pending ad work, clears loaded ads, and makes no further Google Mobile Ads requests for the remainder of that app session.

Subscriptions are purchased and verified through Apple's StoreKit. Apple processes the purchase. Net Results reads whether the ad-free entitlement is active and records the resulting ads or paid mode plus purchase or restore events in first-party analytics; it does not receive or store full payment-card details.

Issue reports

When you submit an in-app issue report, Net Results sends:

Network-trace inclusion is on by default when captured activity is available. The report sheet explains the categories of data the trace may contain before you send the report. You can turn off “Include network activity”; when the control is off, the trace is not sent.

The network trace can contain request URLs and query values, request bodies, response data, and the player or team information used on that screen. It omits authorization, cookie, token, and secret headers and redacts JSON fields whose names indicate passwords, tokens, cookies, or secrets. This reduces exposure but does not make the trace anonymous. Do not include passwords, authentication codes, or other sensitive information in the description or screenshot.

Reports are sent through the Net Results API and created as issues in the private Net Results GitHub repository. Screenshots and network traces are stored as private repository assets for troubleshooting. The API also uses the requesting IP address temporarily in memory to limit report submissions; the IP address is not included in the GitHub issue.

Information stored on the device

In addition to account and session information described above, Net Results stores:

Cached API responses expire automatically, and the app removes expired, unreadable, and older entries to keep the on-device cache bounded. UTR rating responses are not stored in the app's on-disk API response cache. Recent searches can be removed from the recent-search list, account sessions can be removed by signing out, and saved credentials can be removed by turning off Face ID for the account.

Information you choose to share

Nearby lineup sharing uses an encrypted local Wi-Fi or Bluetooth connection. While you are signed in and the app is open in the foreground, your signed-in player name and gender are advertised to nearby Net Results users so they can identify you; a generic device label is used if the player name is unavailable. A sender first shares short-lived match, sender, and target-team identifiers so the app can verify that the signed-in recipient plays on the opposing team before showing an approval prompt. The lineup is sent only after the recipient approves. A completed lineup share contains the lineup, any match or lineup notes the sender chose to include, sender and target team IDs, sender USTA player ID, match ID and date, and short-lived transfer identifiers and timestamps used to reject duplicate or expired transfers. Accepted lineups remain in app memory for the current account and are cleared when the account changes, the user signs out, or the app closes. Sending a lineup through Messages passes the previewed lineup text and any match or lineup notes you chose to include to Apple's Messages composer. Captain and co-captain drafts can be pre-addressed to the opposing captain and co-captain. The More option passes the same previewed text to the iOS share sheet and the destination you choose, such as Mail, AirDrop, a third-party app, or Copy. When a team captain or co-captain taps Contact for another roster player, the app passes that player's phone number and the prefilled greeting to Apple's Messages composer. The signed-in player does not receive a Contact action for themselves.

Calendar features ask for Calendar access only when you choose the calendar action or tap a match date. With your permission, the app reads and displays events from the selected match day on your device so you can see whether the match fits your schedule. When you import upcoming matches from a player profile, the app also reads events that overlap those matches so it can show schedule conflicts before importing anything. Existing calendar events are never changed or deleted during this import. Calendar event titles, times, locations, notes, and other event details are not sent to the Net Results API or analytics. The app can add or update match events using the selected team's opponent, schedule, notes, and venue details. A match without a known time can be added as an all-day event. The app stores the corresponding calendar event identifiers on your device so it can recognize existing matches and update them when a schedule changes. It also embeds a Net Results match identifier in added events so it can recognize them if the app's local settings are reset; those identifiers are not sent to the Net Results API. Events are handled by Apple and your chosen calendar account under their privacy practices.

Service providers and retention

Net Results relies on Render for API hosting, Valkey for temporary response caching, Elasticsearch for playing indications, venue ratings, notification messages and read state, reminder delivery records, and analytics, Resend for venue-review moderation emails, GitHub for private issue reports, Google Mobile Ads for advertising, Apple for notifications, subscriptions, Maps geocoding, WeatherKit forecasts, and system sharing, and the other tennis-data and geocoding services described above. Those providers may receive normal connection information such as IP address and request metadata and process it under their own terms.

The API's application log records a request ID, HTTP method, path, response status, and duration for operational troubleshooting. A path can contain a player, team, match, or venue ID. The request logger excludes query strings, cookies, and request bodies.

Cached tennis data expires or is evicted as described above. App Store privacy disclosures and this policy should be reviewed whenever these data flows or a third-party SDK changes.