Data Protection Notice and FAQ

Greetings Developers!

We’ve reached out to inform our community about some policy changes regarding data protection on the Developer Portal. Blizzard will be giving its players greater control of their data. These changes will directly affect how our developers interact with the content found on our Developer Portal. What does that mean for you?

NEXT STEPS:

  1. When you login to the Developer Portal with your Blizzard account after October 1st, 2019, you must review and accept the new Terms of Use agreement. You must accept the new Terms of Use in order to continue accessing our APIs.
  • You will need to start refreshing player data no less frequently than every 30 days, as it could belong to a user who has asked for their data to be made private or erased.
  1. In the information you provide to us about your client(s), there will be new required fields that you must complete per client:
  • Intent of use – What type of content will you be creating with the data you receive from us? What do you intend to do with it? For example: leaderboard website, guild spreadsheet, etc.

  • URL – Link to the location of the final product; Where can we find your epic content?

DEADLINE:

The process to bring all of Blizzard’s consumers of data into compliance begins October 1st , 2019. We will begin to enforce the data protection policy on January 2nd, 2020. If you haven’t taken all the steps to become compliant, you will receive an error when you attempt to call a Blizzard API endpoint.

There are additional updates to certain World of Warcraft endpoints that will be coming soon as well. Please check out this thread for more information.

Our developer community is an amazing place, thriving with an abundance of talent. We love seeing what our developers create and look forward to witnessing even more of that creativity and innovation—with additional protection for your player data. For more information, please check out the FAQ in the next post on this thread. If you would like to review the Terms of Use at any time, you may find all of our legal documentation here.

Happy coding, developers!

1 Like

We understand that these changes may create additional work for our developers, so we wanted to share this list of Frequently Asked Questions we’ve put together:

1. With the changes regarding data protection, how do I ensure I remain in compliance?

  • When you return to the Developer Portal and login with your Blizzard account after October 1st, 2019, you must review and accept the new Terms of Use agreement. You must accept the new Terms of Use in order to continue accessing our APIs.

  • You will need to start refreshing player data no less frequently than every 30 days, as it could belong to a user who has asked for their data to be made private or erased.

  • In the information you provide to us about your client(s), there will be new required fields that you must complete per client:

    • Intent of use – What type of content will you be creating with the data you receive from us? What do you intend to do with it? For example: leaderboard website, guild spreadsheet, etc.

    • URL – Link to the location of the final product; Where can we find your epic content?

2. What do you mean I have 30 days to “delete” or “refresh” data?

We value our players’ privacy and their right to determine what happens with their player data. By refreshing any retained data every 30 days, it allows the data to remain current and relevant. This ensures there is never out-of-date player data and provides an option for players to ask for their data to be hidden - if they so choose.

3. What happens if I’m not in compliance?

Enforcement for data protection policies will go into effect after January 1st, 2020. After this point in time, if you retain player data that is no longer valid or accurate, you will lose access to Blizzard Game Data, Community, or Profile APIs.

4. Who does this affect? If I live in “x” region of the world, does this apply to me?

Blizzard Entertainment is a global company; players of our games live all around the world. We value the protection of all our players’ data, and as such, this applies to everyone who consumes any data from our APIs.

5. What happens if I haven’t updated my client to use a new client token?

There will be monitoring of all clients. If you are found to be non-compliant, you risk losing access to our public APIs.

6. Instead of deleting player data, can I simply anonymize it?

Because there’s no defined threshold of anonymity, we don’t want to take the chance. We want all our players and developers to be as protected as possible. In short: please adhere as closely to the data lifespan of 30 days as possible.

7. What happens if player data I’d deleted in the past suddenly shows up again?

If you’ve made a new call in the next 30 day window and the data appears again, the possibility of retaining possession of the data has been made available once more. Should it disappear again, it is safe to assume that you must delete it at that point in time.

8. How does a client remain in compliance if it does not use a URL (Example: An executable or database and not a website)?

Underneath the form field in the client information, there is a box users can check to indicate there is no service URL.

9. Is a seven-day buffer period allowed to accommodate for returned API call inconsistencies?

The window of time data can live is thirty days. If a user chooses to make a call seven days prior to the 30th day to allow for data inconsistencies, there is nothing unallowable about this action. However, anything past 30 days is non-compliant.

10. Does a unique character ID persist across servers? For example, if a player were to transfer from Proudmoore to Illidan, would the character ID remain the same for the character they transferred?

The unique ID does not persist across servers. If a character is transferred, the old character data with the previous character ID should be deleted.

11. Is there an option to hide the data within your client or database rather than truly deleting it?

In order to ensure full compliance with the new policy, developers should delete the data if you receive a 404 – Not Found error.

12. Will Blizzard be increasing the rate limits for any endpoints?

Not at this time, though we are aware that the new policy will require an increase in API calls. We will be monitoring endpoint usage to determine whether increases are warranted, but as of this time, the intent is for the rate limits to remain unchanged.

13. What exactly is the intent of the ‘/character/:realm/:characterName/status’ endpoint, and how should it be used?

This is a three-part answer. We apologize for the length but want to ensure we answer the question in the most thorough format:

  • Any data retrieved from any character endpoint must be validated every 30-days to ensure the user remains in compliance. The ‘/status’ endpoint allows the user to avoid checking individual character endpoints, instead only calling a single endpoint. However, the relationship doesn’t work the other way around; a valid response from ‘/status’ implies that ‘/character/:realm/:characterName’ is valid, but calling ‘/character/:realm/:characterName’ and receiving a valid response does not imply the rest of the endpoints covered by ‘/status’ is valid.

  • The ‘/status’ endpoint will only start returning data for players who have logged in since October 2, 2019 at 4PM Pacific Time. All player data older than that date will return a 404 – Not Found error.

  • Any data that exists at an endpoint is approved to store for 30 days. For older character data before October 2, 2019 at 4PM Pacific Time, the ‘/status’ endpoint will return a 404, but if the data still exists within a different endpoint for the same character, that data set may be used for 30 days.

If there are any questions not answered by the notice or the FAQ, please feel free to post additional questions here in this thread!

1 Like

Eh, what if my API using programs are plain executables, not web sites, so they don’t even have a “URL”?

To clarify: I use the API to get access to information about my own characters, as well as AH data from the realms I play on. (There is no public access to my API-using apps, since they are not web sites.). I do so from the WoW Community APIs, using the client credential flow, not via user authentication.

1 Like

Does this apply to all profile/game related data as well? Or just BattleNet user profile data? For example - if I consume the /profile/wow/character/{realmSlug}/{characterName} endpoint, does that data need to be refreshed within a 30 day window?

1 Like

A. Please explain how these types of information are impacted by these new changes, as each has different implications:

  • User identifying information from the oauth flow, e.g., account id and battletag.
  • List of associated game characters from the oauth flow.
  • Data for characters from the public APIs.

B. How does this affect information that is static or pushed to users?

  • A discord bot that posts the character of someone applying to the guild.
  • A guild website application form retaining the character of someone who applied to the guild.
  • Various implications regarding WCL retaining character information about a specific fight.

C. Could anything be done to include in the API a truly unique identifier for characters?

While some users may enjoy new privacy features, a majority of players do not want their online character achievements across various sites being erased with no possibility of transferring them. This would have a negative impact on guild recruitment and adoption of community websites if after every time someone leaves a server or changes their name their WCL and RaiderIO information is permanently lost.

D. Could the /status character endpoint also include lastUpdated if the character is valid? This could cut down on the number of API requests by a lot.

E. Could we have a legally strict definition of what must be deleted? Can we keep the character’s name-realm-region association and/or id?

An example would be an attendance tracker (among other things) where deleting information immediately upon character disappearance would ruin the functionality completely. Data that is not owned by the player but requires a character association.

2 Likes

I had the same concern, and when I logged in it required me to update my service because the Service URL was missing. But it also offered a checkbox to indicate that my use was not a website. The checkbox says:

1 Like

Seconding what Solemnity asked about. Does this new policy apply to SSO via oauth as well?

To be concrete, I store the Battle net ID as the identifier to login and as the link to the user account on my page. This data I cannot refresh from my side because the refresh token expires after 24h. If a user then does not log in for 30 days, am I required to delete their Battle net ID, since it’s “player data”?
This would essentially mean they lose access to their account and it would make the entire SSO feature largely useless. I can’t imagine this is intended behaviour but the policy change does read so.
A clarification about this would be highly appreciated :slight_smile:

1 Like

This is what I want to know too. My site makes absolutely no calls to the player-data APIs, and only access guild-APIs… the same information that is on the Armory. Do I still have to comply with this data protection thing, and if so, how do I do that since I retrieve no actual player-specific data.

Per the Discord -

“The data you retrieve from each character endpoint must be re-validated every 30 days, per-endpoint. The /status endpoint allows you to avoid doing a check on every single character endpoint you may pull data from, and only check this one endpoint. The relationship doesn’t work the other way around; /status is valid implies /character/:realm/:characterName is valid, but /character/:realm/:characterName is valid does not imply the rest of the endpoints, covered by /status , is valid.”

So it sounds like that data is specifically what we need to clear out if a status is unavailable. Since we need to migrate over to the Profile API anyway, it would make sense that you will only receive negative data from your guild members who request to have their data removed. I think it’s an all or nothing thing… which is kind of sad. I can see people rejecting an app like WoWProgress, but allowing data to be shared for a guild website.

I got a few follow up questions on this change

  1. What is the grace period/rules for deleting data on 404 - Is it 404 AND 30days sense last good response or immediately on 404 regardless of time. I would hope its the first case otherwise if the API is acting up you could be forced to delete valid characters?

  2. Can we get some confirmation that older characters who have not logged in recently will be available to the new api endpoint so they can be saved if not some other alternative? Warcraft sites live and thrive on historical data, being forced to delete someone’s Legion All Time High scores because they haven’t logged in would provide a horrible UX when they return and ask where there scores are and you have to explain you deleted them.

  3. How can we go about requesting a Rate Limit Increase. My app along with many others already sit at 99% utilization of the API. With the current 30 Day deletion check + the current 36,000/hr that hard caps apps to contain knowledge of less then 12,960,000 characters. This number drops drastically when you consider the fact that you must do multiple API requests in place of a single one. So, if you do advanced character lookups with collection data, raid data, etc. Your hard capped at less than 2 million characters, and that number assumes your only ever looking up a single character once per month.

  4. Is there any update if the newly created character ID persists across transfers/changes?

  5. What is the deletion expectation for not /profile/character/status data? IE: lets say someone uses the /profile/{account-id}/wow endpoint - the tokens from the User Authentication flow are only valid for 24hrs. We can’t recheck to see if we should delete them… ever.

Proposal to fix concerns with Data deletion

When storing data in your app/database characters are identified by ID / Name / Realm / Region with a bunch of other accenting data (ilv, gear, prog, etc)

When a request to delete comes in, you should replace or delete the (Name/Realm/Region) this way the data, in the case of belonging to a raid log, M+ Leaderboard, or any other collective can still be whole, but the players name would be replaced with "Removed" or "Deleted" - That way completely anonymous data about the character such as item level, prog history, scores, etc can be preserved without actually linking back to an identifiable character. Should that ID ever re-activate you can re-attach the data in the future

We’re compiling a list of answers for the questions and concerns y’all have posed. Keep 'em coming, and stay tuned!

1 Like

I haven’t logged in yet because I don’t know how to fill out the form.

I have a client (currently the only one), that is for local development only. If something I write goes into productive use, it’s supposed to get it’s own client, registered by the person who runs the website that uses it.

So, what would be my service URL? I’m programming in PHP, so I don’t think I’ll get away with claiming that there is none. Everything I write is technically a website.

What would be the intend of use? “Development”, maybe “prototyping” or just “let’s see what can be done”? If I have to specify “how and from where” I am calling the API, will “curl” and “localhost, or whatever fake domain I add to my hosts file” be a valid answer?

If your app isn’t published you don’t have a valid URL, so you can check that option. As of the usage you can tell details of what you are trying to achieve. If anyone decides to use they’ll have to provide those details themselves and give a URL, just make sure you don’t publish your credentials.

1 Like

I believe that the field allows you to put a detailed description if you want.

@Araspir question for your list of answers: Does it matter how descriptive this field is?

For example, I simply put “I use the API to generate a guild website”. Is that enough?

Any updates on this?

Also, is the /status endpoint going to be used to enforce the data protection policy?

I’m looking at simply enforcing a 30 day retention policy for all of my character/sim data to ensure I don’t run afoul of the policies and want to make sure this is adequate.

1 Like

The FAQ post at the top of the thread has been updated with additional questions.

We appreciate everyone’s patience during this process, and encourage you to continue sharing your questions in this thread. We will continue to monitor responses and update the FAQ accordingly, but unfortunately, cannot answer all specific use cases.

Thank you!

I have an app (wow-query.dev) where a user can sign in with their Battle Net credentials, however I do not use their token to retrieve any character related data.

However I do use their battletag and ID to persist data they generated in my app. In this case there is no way I can check if a user wants their data deleted.
My point is: in this context is user data restricted only to World of Warcraft characters ? Do I have to worry about Battle Net account data ? If so should I delete data for anyone who hasn’t signed in within 30 days ?