Privacy and Data Obligations

How did we do?

When you use HiveMP Sessions in your application or game, you have privacy and data storage obligations that you must follow in order to comply with our Terms of Service.

Do not transmit or store user profile information

You must not transmit, copy or store user profile information received from the API to any external system. This includes caching display names, full names, avatar URLs or any other profile information.

The only exception to this rule is that you may store the user account ID in external systems to identify the user account.

  • Do not transmit or store the full name, display name or any other field of the profile.
  • Do not transmit or store information about users to external systems, with exception of the user account ID.
  • Do not transmit, cache or store information about a user's friends.
  • You may cache user information in memory on the local client computer to reduce the calls made to the API, up to a maximum of 60 minutes or when the user session expires, whichever is sooner. Do not persist this data to disk.

Example: Referencing users in an external system

Let's say you're building a web application or an API that is connected to HiveMP, and you want to identify users in that application so you can link custom pieces of data against them.

In this case, you can store the user account ID in your system, but no other user-related data from HiveMP. For example, you can't store the display name or full name of a user in your database.

If your application needs to access other profile fields at runtime, it should make a request to the appropriate HiveMP API to retrieve that data at runtime, while acting as the user that will view that data.

Example: Showing information about users in external system

Let's say you're building an online web application where users can give other users "badges", and you want to display information about users in that system so that the person viewing the web page can view a user's display name and badges they've been given.

You need to comply with HiveMP's data obligations in this application. Specifically, you can't show any user data without the person viewing the web page having logged into their HiveMP account. This is because you can't store or persist profile data (the display name), and you are unable to request a user's profile data at runtime without having an active session API key.

This also means that you can't show display names on users that the viewer isn't friends with or whose profiles aren't publicly discoverable. You will only be able to retrieve the display name on users through the API who the user is friends with or who have made their display name public with the appropriate setting in the Account Portal.

Depending on how "revealing" the badges and other data you have stored against users is, you should not display data for any user that you can't retrieve HiveMP profile data for. That is, even though you have the user account ID for unrelated users (not friends, not public), you should not show the badges for those users in case it allows a viewer to "figure out" who that user is if they shouldn't otherwise be able to.

Do not transmit user information to third-parties

You must not transmit user information (including user account IDs and session IDs) to third-parties. This means that the user of external analytical providers is strictly forbidden when it comes to user data.

You can store user account IDs in HiveMP Event Tracking, but this may incur additional obligations on your behalf to confirm to privacy laws and regulations.

  • Do not transmit any user information, including user account or session IDs to third-parties.
  • Do not transmit device information such as unique device identifiers without the user's consent. Please note that in some regions this kind of data storage or transfer is forbidden by law, regardless of whether the user consents or what system the identifiers are being transmitted to.
  • Do not store user data such as display names or other profile fields (with the exception of user account IDs or session IDs) in HiveMP Event Tracking.

Do not automatically initiate actions on the user's behalf

You must not automatically send friend requests, chat messages, modify the user's profile or initiate purchases without the user actively initiating the action.

  • Do not update the user's profile in your game unless the user actively initiates the action.
  • Do not send, rescind, accept or reject friend requests unless the user's actively initiates the action.
  • Do not automatically send chat messages that the user didn't type and actively send themselves.
  • Do not pre-fill chat input boxes with your own messages, or in any way attempt to get users to send predetermined messages.
  • Do not initiate password reset requests, 2FA enablement or other account management flows unless the user actively initiates the action. These flows are protected through separate email confirmation and can not be fully controlled via the API.
  • Do not initiate purchase requests without the user actively initiating the action themselves. These flows are protected through separate email confirmation or 2FA and can not be fully automated through the API.

Do not intercept authentication requests

You must not cache or re-transmit the data provided to authentication endpoints, including email addresses or password hashes.

  • Do not store, cache or transmit user email addresses. You must only keep this information in the local memory of the client and only transmit it to the authentication endpoint when requested to do so by the user. If you want to send emails to users, HiveMP provides this functionality to you without disclosing their email addresses.
  • Do not store, cache or transmit passwords either in plain text or hashed, except to the authentication endpoint.
  • Do not automatically fill in the "Marketing Preference" field for the user, except when the value of the field is false. Marketing preferences are strictly opt-in and you must not automatically send a value of "true" for this field, or default any checkbox or UI element indicating marketing preferences to "true".
  • You may send implicit non-OAuth tokens to your own services for authentication if you want to. These implicit tokens must be directly provided to the game or application by the native platform (e.g. this is only permitted for itch.io and Steam which provide implicit login tokens through environment variables and a native API respectively).

Do not use API keys you don't have permission to use

You must not use API keys that you don't have permission to use, or misuse API keys outside their original intended purpose. This includes using other developer's API keys.

  • Only use your own API keys for projects that you own.
  • Do not retrieve, reverse engineer or use API keys from other websites, services, applications or games under any circumstances.

Do not mislead users

You must not mislead users as to the origin of your application or game. This includes falsifying public information about your project (which is used in OAuth flows on the web).

  • Do not use the names of other companies, brands, games or applications that you do not own in HiveMP.
  • You must make sure the origin of your application is clear to users at all times, and that they are able to identify you as a developer for the purpose of verifying authenticity of the application.

What to do if you're in doubt

If you're unsure whether or not something you want to implement complies with these obligations, please reach out to our support channels so that we can advise on an individual basis.