Viserio Cooldowns API: Data Handling

How we decide what to expose

The starting point is minimization: the API returns the data a real coordination flow needs, not everything we hold. Before a field is exposed we ask whether a genuine integration needs it, whether it is information the member entrusted to us rather than ours to hand on, and whether sharing it stays in good faith with Blizzard’s Battle.net / WoW, Warcraft Logs, and Raider.io API terms. When in doubt we leave it out and add it later if a real use case appears.

What the API exposes

For a group whose admin has enabled API sharing, that group’s API key can read:

• Group metadata: name, member count, linked guild (region/realm/name).
• Roster: member display names, ranks, roles, optional aliases and battletags, and their characters (name, realm, class, spec).
• Resets: names, week references, setups, boss order, roster references.
• Calendar: scheduled raid nights and each event’s signups (who is coming and in what role) and the schedules behind them. Personal signup comments are not exposed.
• Loot wishlists: each character’s wished-for items, their priorities and notes, and when the wishlist was created and last edited.
• Droptimizers: when each sim was uploaded, which profile it is, the baseline, and a link to the full report at its source. The detailed item-gain tables behind a sim are not re-served here.
• Cooldown notes and assignments: metadata and structure only (boss, difficulty, names, counts, links). The actual note text and assignment tables are not exposed.

What the API never exposes

A battletag is the public social handle a member shares by signing in, and it is exposed only for an opted-in group. What we never expose is the private Battle.net account number we authenticate them with (the OAuth sub): every resource is addressed by our own identifiers, never a provider’s. We also never expose supporter or payment identifiers, third-party access tokens, or any internal system data. We hold no user email addresses at all, so there are none to leak. Who claimed a roster spot is reduced to a yes/no; the underlying account is never sent.

Consent model

• Data is served for a group only after a group admin enables API sharing. The key is a group credential created by an admin; there is no per-person access. A supporter boost is not required for access; it only raises the request quota.
• When a group disables API sharing, access to that group’s data stops within a short cache window.
• An individual whose battletag appears can ask a group admin to disable the group’s API sharing or remove them from the roster, since the opt-in is the admin’s to set. We step in to disable a key directly where there is cause, such as abuse, a policy breach, or a legal obligation.

What we log

Request metadata only: timestamp, method, path, key id, client IP address, and response status, plus rate-limit and abuse accounting. The IP address is needed to detect and block abusive traffic. We do not log response payloads. Logs are retained only as long as needed for abuse investigation and capacity protection.

Obligations on API consumers

• You are responsible for data you store. Hold exposed personal data (battletags, character names) only as long as your integration needs it.
• Do not create a permanent mirror. Delete cached data within 30 days unless it is refetched. A refresh-based cache that re-fetches and expires data is acceptable; a permanent copy is not.
• Delete a group’s data when that group’s access is removed or its opt-in is withdrawn.
• Respect Blizzard’s Battle.net / WoW API terms for any stored or displayed data.
• Do not surface a guild member’s information where that member has not agreed to it, and do not use the data to identify, contact, or profile individuals beyond the guild-tooling purpose.
• Secure stored data at least as carefully as your own account credentials.

Our commitments

• Mostly reads. The few writes are narrow and stay within the group’s own coordination data (for example, setting a member’s calendar signup status, or importing a droptimizer for one of the group’s own roster characters). A key can never reach beyond its own group, and database access is least-privilege.
• Group admin opt-in enforced on every request; boost only sets the quota.
• One key per group, admin-managed, hashed at rest, shown only once.
• Booster identities are never exposed, only aggregate boost totals.
• We act on opt-out and revocation promptly.

Contact

Questions or concerns about the data the API handles: [email protected].