Referenced in any endpoint with querystring parameters such as Destiny2.GetProfile

components
A comma separated list of components to return (as strings or numeric values). See the DestinyComponentType enum for valid components to request. You must request at least one component to receive results.
Type: string

This was brought up already, but I'm adding it to github so it doesn't get lost

I noticed that the urls for Array type components (ie https://bungie-net.github.io/multi/schema_BungieMembershipType[].html#schema_BungieMembershipType[]) have "[]" in the url. While it appears to be valid, its probably not good practice to have brackets in the url. The regular expression for generating the filepaths should be replace(/[\<\>\.,\[\]]/, "-")

The JavaScript validation on the page blocks redirect urls such as, myapp:/oauth. Bypassing the JavaScript to submit the form data persist correctly.

Please consider adding a response header to API requests that indicates something like "We would appreciate it if you make this request less frequently, and will rate-limit you if you ignore us; please wait at least X seconds before sending it again".

I've seen this done after a rate-limit event occurs, and it's invaluable in that scenario as well, where you say "Your rate limit will expire in X seconds", so that clients can schedule a timer and stop bothering the server.

It also provides several opportunities:

• By randomizing X slightly (+/- 1%) you ensure a more even distribution of API clients over time, whether in reaction to an outage or simply load.
• You can yourself and cellular users a lot of pointless requests during partial outages by including X=300 +/- seconds in your downtime responses, so that well-implemented clients override their native retry interval (which will always be the minimum permitted).
• Clients that frequently make expensive requests can be assigned a higher X due to the cost of the queries.

So, this would (I'm making this up on the fly) look something like:

X-Rate-Limit: pause=67

Long-term, there's another interesting point. If you simply declare this a header that's mandatory to support, then you also gain the ability to stop advertising hard limits and can instead calibrate your rate limits dynamically, based on server load and all that jazz, using X-SDP headers:

X-Rate-Limit: pause=0, interval=31 (30 +/- randomized)

There's probably months of work possible down these lines of thinking to make a rockstar-grade API with server-autotuned refresh intervals granular to endpoints, so I'm going to pause here and let you consider the idea in general first :)

Hey everyone,
I've been beating my head against the wall with the authentication process. I'm attempting to use the code provided by the re-direct to get the api token (api, refresh token) and I keep getting the same error message from Bungie:

{
  ErrorCode = 2106;
  ErrorStatus = AuthorizationCodeInvalid;
  Message = "Authorization code is invalid.";
  MessageData = {};
  ThrottleSeconds = 0;
}

The code given to be looks like this: M11A1A11A-A1A1-11A1-11A1-A1A11AA11A1A which doesn't match the examples I see (I've swapped all letters and numbers for As and 1s). Is this a valid format or do I have to do something to it? Like hashing it or something?

Note I'm trying this using an Xbox Login.

Documented here

I'm curious if the key is an item hash or an item instance id. Thanks!

I'm working on a Ruby gem (no UI) to wrap some commonly used API calls. Given that there are no credentials for bungie.net proper, is this flow even supported? I.e. what client key and secret do I use to kick off OAuth Implicit with Bungie?

Hitting this url https://www.bungie.net/Platform/Destiny2/1/Account/4611686018430034191/Character/2305843009260584043/Stats/Activities/?mode=5&count=100&page=0

This guy according to the AllTime stats has played 18 games. As you can see in the url, I'm asking for mode 5, all pvp, but I'm not getting all 18 games.

I am aware of the topic: Question: OAuth Client Type for native apps, but I thought it was needed to create an issue for this specific alternate authentication mode.

Can it be assumed you have completely dropped this support, including for Destiny 1? If it is still possible to use WebView authentication, am I missing something that has changed?

I ask because end points to retrieve game data are limited to public information only. Even though I was able to successfully authenticate and am passing all of the proper cookies along.

Request headers:

GET https://www.bungie.net/d1/Platform/Destiny/1/MyAccount/Vault/ HTTP/1.1
X-CSRF: ***
X-API-Key: ***
Host: www.bungie.net
Cookie: bungleatk=***; bungled=***; bungledid=***; bunglefrogblastventcore=***; bungleloc=lc=en&lcin=true; bungleme=***; bunglemsa=***; bungles=WebView=True&UserFlowMode=SignIn&UserICT=None&UserSCT=None&UserForce=False&UserIDN=; sto-id-sg_live.bungie.net=***; __cfduid=***

Response:

{"ErrorCode":99,"ThrottleSeconds":0,"ErrorStatus":"WebAuthRequired","Message":"Please sign-in to continue.","MessageData":{}}

I've been working on getting values for the weekly nightfall, and I'm having an issue fetching one of the 'challenges' from the Manifest database. The other two values are both there, but the third isn't for some reason.

The hash ID is 4148319260, and I'm looking in DestinyObjectiveDefinition. Does anyone know why this is happening?

Display Name the player has chosen for themselves. Thie display name is optional whenthe data type is used as input to a platform API.

As the title states. Also might be handy to have a link to the Official Help Article (which probably needs to be pulled out of the BNet Group)

I'll keep working my way down the list slowly, but I think this is my last one for tonight.

So much of what you see in Destiny is actually an Item used in a new and creative way. This is the definition for Items in Destiny, which started off as just entities that could exist in your Inventory but ended up being the backing data for so much more: quests, reward previews, slots, and subclasses. In practice, you will want to associate this data with "live" item data from a Bungie.Net Platform call: these definitions describe the item in generic, non-instanced terms: but an actual instance of an item can vary widely from these generic definitions.

secondaryIcon
A secondary icon associated with the item. Currently this is used in very context specific applications, such as Emblem Nameplates.

secondaryOverlay
Pulled from the secondary icon, this is the "secondary background" of the secondary icon. Confusing? Sure, that's why I call it "overlay" here: because as far as it's been used thus far, it has been for an optional overlay image. We'll see if that holds up, but at least for now it explains what this image is a bit better.

secondarySpecial
Pulled from the Secondary Icon, this is the "special" background for the item. For Emblems, this is the background image used on the Details view: but it need not be limited to that for other types of items.

screenshot
If we were able to acquire an in-game screenshot for the item, the path to that screenshot will be returned here. Note that not all items have screenshots: particularly not any non-equippable items.

itemTypeDisplayName
The localized title/name of the item's type. This can be whatever the designers want, and has no guarantee of consistency between items.

itemTypeAndTierDisplayName
It became a common enough pattern in our UI to show Item Type and Tier combined into a single localized string that I'm just going to go ahead and start pre-creating these for items.

displaySource
In theory, it is a localized string telling you about how you can find the item. I really wish this was more consistent. Many times, it has nothing. Sometimes, it's instead a more narrative-forward description of the item. Which is cool, and I wish all properties had that data, but it should really be its own property.

tooltipStyle
An identifier that the game UI uses to determine what type of tooltip to show for the item. These have no corresponding definitions that BNet can link to: so it'll be up to you to interpret and display your UI differently according to these styles (or ignore it).

action
If the item can be "used", this block will be non-null, and will have data related to the action performed when using the item. (Guess what? 99% of the time, this action is "dismantle". Shocker)

inventory
If this item can exist in an inventory, this block will be non-null. In practice, every item that currently exists has one of these blocks. But note that it is not necessarily guaranteed.

setData
If this item is a quest, this block will be non-null. In practice, I wish I had called this the Questblock, but at the time it wasn't clear to me whether it would end up being used for purposes other than quests. It will contain data about the steps in the quest, and mechanics we can use for displaying and tracking the quest.

stats
If this item can have stats (such as a weapon, armor, or vehicle), this block will be non-null and populated with the stats found on the item.

equippingBlock
If this item can be equipped, this block will be non-null and will be populated with the conditions under which it can be equipped.

translationBlock
If this item can be rendered, this block will be non-null and will be populated with rendering information.

preview
If this item can be Used or Acquired to gain other items (for instance, how Eververse Boxes can be consumed to get items from the box), this block will be non-null and will give summary information for the items that can be acquired.

quality
If this item can have a level or stats, this block will be non-null and will be populated with default quality (item level, "quality", and infusion) data. See the block for more details, there's often less upfront information in D2 so you'll want to be aware of how you use quality and item level on the definition level now.

sourceData
If this item has a known source, this block will be non-null and populated with source information. Unfortunately, at this time we are not generating sources: that is some aggressively manual work which we didn't have time for, and I'm hoping to get back to at some point in the future.

objectives
If this item has Objectives (extra tasks that can be accomplished related to the item... most frequently when the item is a Quest Step and the Objectives need to be completed to move on to the next Quest Step), this block will be non-null and the objectives defined herein.

plug
If this item is a Plug, this will be non-null and the info defined herein. See DestinyItemPlugDefinition for more information.

sack
If this item is a "reward sack" that can be opened to provide other items, this will be non-null and the properties of the sack contained herein.

sockets
If this item has any Sockets, this will be non-null and the individual sockets on the item will be defined herein.

talentGrid
If the item has a Talent Grid, this will be non-null and the properties of the grid defined herein. Note that, while many items still have talent grids, the only ones with meaningful Nodes still on them will be Subclass/"Build" items.

investmentStats
If the item has stats, this block will be defined. It has the "raw" investment stats for the item. These investment stats don't take into account the ways that the items can spawn, nor do they take into account any Stat Group transformations. I have retained them for debugging purposes, but I do not know how useful people will find them.

loreHash
If the item has any related Lore (DestinyLoreDefinition), this will be the hash identifier you can use to look up the lore definition.

summaryItemHash
There are times when the game will show you a "summary/vague" version of an item - such as a description of its type represented as a DestinyInventoryItemDefinition - rather than display the item itself. This happens sometimes when summarizing possible rewards in a tooltip. This is the item displayed instead, if it exists.

animations
If any animations were extracted from game content for this item, these will be the definitions of those animations.

nonTransferrable
The intrinsic transferability of an item. I hate that this boolean is negative - but there's a reason. Just because an item is intrinsically transferrable doesn't mean that it can be transferred, and we don't want to imply that this is the only source of that transferability.

itemCategoryHashes
BNet attempts to make a more formal definition of item "Categories", as defined by DestinyItemCategoryDefinition. This is a list of all Categories that we were able to algorithmically determine that this item is a member of. (for instance, that it's a "Weapon", that it's an "Auto Rifle", etc...) The algorithm for these is, unfortunately, volatile. If you believe you see a miscategorized item, please let us know on the Bungie API forums.
^^^ Github repo instead of Bungie API forums?

specialItemType
In Destiny 1, we identified some items as having particular categories that we'd like to know about for various internal logic purposes. These are defined in SpecialItemType, and while these days the itemCategoryHashes are the preferred way of identifying types, we have retained this enum for its convenience.

itemType
A value indicating the "base" the of the item. This enum is a useful but dramatic oversimplification of what it means for an item to have a "Type". Still, it's handy in many situations. itemCategoryHashes are the preferred way of identifying types, we have retained this enum for its convenience.

itemSubType
A value indicating the "sub-type" of the item. For instance, where an item might have an itemType value "Weapon", this will be something more specific like "Auto Rifle". itemCategoryHashes are the preferred way of identifying types, we have retained this enum for its convenience.

classType
We run a similarly weak-sauce algorithm to try and determine whether an item is restricted to a specific class. If we find it to be restricted in such a way, we set this classType property to match the class' enumeration value so that users can easily identify class restricted items. If you see a mis-classed item, please inform the developers in the Bungie API forum.
^^^ Github repo instead of Bungie API forums?

damageTypeHashes
Theoretically, an item can have many possible damage types. In practice, this is not true, but just in case weapons start being made that have multiple (for instance, an item where a socket has reusable plugs for every possible damage type that you can choose from freely), this field will return all of the possible damage types that are available to the weapon by default.

damageTypes
This is the list of all damage types that we know ahead of time the item can take on. Unfortunately, this does not preclude the possibility of something funky happening to give the item a damage type that cannot be predicted beforehand: for example, if some designer decides to create arbitrary non-reusable plugs that cause damage type to change. This damage type prediction will only use the following to determine potential damage types: - Intrinsic perks - Talent Node perks - Known, reusable plugs for sockets

defaultDamageTypeHash
Similar to defaultDamageType, but represented as the hash identifier for a DestinyDamageTypeDefinition. I will likely regret leaving in the enumeration versions of these properties, but for now they're very convenient.

redacted
If this is true, then there is an entity with this identifier/type combination, but BNet is not yet allowed to show it. Sorry!

User has privacy controls appropriately enabled on Bungie.net. According to the description, this should be returning public data.

https://www.bungie.net/Platform/Destiny2/2/Profile/4611686018428440298/Character/2305843009260343992/?components=202

{"Response":{"progressions":{"privacy":2},"itemComponents":{}},"ErrorCode":1,"ThrottleSeconds":0,"ErrorStatus":"Success","Message":"Ok","MessageData":{}}

https://www.bungie.net/en/Application

You cannot delete applications, you no longer need. For example an application for testing.

I apologize if this is not the place to ask this question. Has anybody gotten passport-oauth2 to work inside of an Express app to authenticate against Bungie's oAuth workflow? I get all the way to callbackURL and Passport throws an error that it cannot parse the response.

I am looking into the design of my IOS app with PHP back end and the possibility of holding the basic data on the device by trimming down the manifest to only the info I require for my app and using a cache for a lot of the images,
limiting the need to request data

The question I have is how often is the manifest updated, is it just a reset day thing and what are the main areas that change. If it is possible to answer that ?

This questions apply's to D1 & D2 , but I assume they both run on a similar principle

Thanks In Advance

I'm working through suuuuper basic authentication via Auth0.com and standard OAuth flow. When I'm signed in with my own account, I can't auth with my public app. However, when I'm signed out I can hit it just fine. Is this because I'm already "authenticated" with the app as the owner?

In the full API spec on github.io, the Content-Entities section mentions some Group-related data (for example, GroupsV2.GroupResponse and GroupsV2.GroupV2ClanInfo), but no Group-related endpoints are provided. Is it possible to expose those endpoints?

Using the newest swagger-client for node, which seems to only support 2.0 specs, I kept getting an error for the server field. the client seems to be adding an extra http beofre the host field so requests become:

http://https://bungie.net/Platform/...

If I removed the https:// at the beginning of the host, it all works correctly and resolves to using https correctly.

I'm not 100% sure if this is a quirk with swagger-client, or an error with the codegen used; just reporting so it's known!

At the very least, thanks for all of the documentation! It's super great to see these endpoints in a documented manner and so organized too! Wondrous! I'm also super pumped for the amount of stats and granularity that can be returned! Let the analytic creativity FLOW!

here is a snipped of the openapi-2.json file that is relevant to this issue:

{
  "swagger": "2.0.0",
  "info": {
    "title": "Bungie.Net API",
    "description": "These endpoints constitute the functionality exposed by Bungie.net, both for more traditional website functionality and for connectivity to Bungie video games and their related functionality.",
    "termsOfService": "https://www.bungie.net/en/View/Bungie/terms",
    "contact": {
      "name": "Bungie.net API Support",
      "url": "https://github.com/Bungie-net/api",
      "email": "[email protected]"
    },
    "license": {
      "name": "BSD License 2.0",
      "url": "https://github.com/Bungie-net/api/blob/master/LICENSE"
    },
    "version": "2.0.0"
  },
  "host": "https://bungie.net",
  "basePath": "/Platform",
  "paths": {}

We should ask around and see if we'd be permitted to allow Postmaster transfers.

In the D1 api we could look up a single hash and get it's definition.

Url is: https://www.bungie.net/d1/platform/Destiny/Manifest/{type}/{hash}/ This was very useful, would love to it make a come back! If it's not possible, I understand. thanks!

Nothing a little decent regex can't fix, but it's still worth mentioning since it can have an impact on any sort of parsing of the API spec (ie Unofficial Wiki, Commented code generated from it, etc).

Note: Also includes
#19
#18
#17

These are ones that weren't large enough for their own issue.

User.UserMembership and User.UserInfoCard

displayName
Display Name the player has chosen for themselves. The display name is optional when the data type is used as input to a platform API.

User.UserInfoCard

This contract supplies basic information commonly used to display a minimal amount of information about a user. Take care to not add more properties here unless the property applies in all (or at least the majority) of the situations where UserInfoCard is used. Avoid adding game specific or platform specific details here. In cases where UserInfoCard is a subset of the data needed in a contract, use UserInfoCard as a property of other contracts.

Partnerships.PartnershipType

Representing external partners to which BNet users can link accounts, but that are not Account System credentials: partnerships that BNet uses exclusively for data.

Queries.SearchResult and SearchResultOfPostResponse and Forum.PostSearchResponse

useTotalResults
If useTotalResults is true, then totalResults represents an accurate count. If False, it does not, and may be estimated/only the size of the current page. Either way, you should probably always only trust hasMore. This is a long-held historical throwback to when we used to do paging with known total results. Those queries toasted our database, and we were left to hastily alter our endpoints and create backward-compatible shims, of which useTotalResults is one.

GroupsV2.GroupResponse

currentUserMemberMap
This property will be populated if the authenticated user is a member of the group. Note that because of account linking, a user can sometimes be part of a clan more than once. As such, this returns the highest member type available.
currentUserPotentialMemberMap
This property will be populated if the authenticated user is an applicant or has an outstanding invitation to join. Note that because of account linking, a user can sometimes be part of a clan more than once.

GroupsV2.GroupFeatures

maximumMembershipsOfGroupType
Maximum number of groups of this type a typical membership may join. For example, a user may join about 50 General groups with their Bungie.net account. They may join one clan per Destiny membership.

GroupsV2.RuntimeGroupMemberType

The member levels used by all V2 Groups API. Individual group types use their own mappings in their native storage (general uses BnetDbGroupMemberType and D2 clans use ClanMemberLevel), but they are all translated to this in the runtime api. These runtime values should NEVER be stored anywhere, so the values can be changed as necessary.

Destiny.DestinyProgression

Information about a current character's status with a Progression. A progression is a value that can increase with activity and has levels. Think Character Level and Reputation Levels. Combine this "live" data with the related DestinyProgressionDefinition for a full picture of the Progression.
currentProgress
This is the total amount of progress obtained overall for this progression (for instance, the total amount of Character Level experience earned)
levelCap
This is the maximum possible level you can achieve for this progression (for example, the maximum character level obtainable)
stepIndex
Progressions define their levels in "steps". Since the last step may be repeatable, the user maybe at a higher level than the actual Step achieved in the progression. Not necessarily useful, but potentially interesting for those cruising the API. Relate this to the "steps" property of the DestinyProgression to see which step the user is on, if you care about that. (Note that this is Content Version dependent since it refers to indexes)
progressToNextLevel
The amount of progression (i.e. "Experience") needed to reach the next level of this Progression. Jeez, progression is such an overloaded word.

Destiny.Definitions.DestinyDefinition and Destiny.Definitions.DestinyProgressionDefinition

redacted
If this is true, then there is an entity with this identifier/type combination, but BNet is not yet allowed to show it. Sorry!

Destiny.Definitions.DestinyProgressionDefinition

A "Progression" in Destiny is best explained by an example. A Character's "Level" is a progression: it has Experience that can be earned, levels that can be gained, and is evaluated and displayed atvarious points in the game. A Character's "Faction Reputation" is also a progression for much the same reason. Progression is used by a variety of systems, and the definition of a Progression will generally only be useful if combining with live data (such as a character's DestinyCharacterProgressionComponent.progressions property, which holds that character's live Progression states). Fundamentally, a Progression measures your "Level" by evaluating the thresholds in its Steps (one step per level, except for the last step which can be repeated indefinitely for "Levels" that have no ceiling) against the total earned "progression points"/experience. (for simplicity purposes, we will henceforth refer to earned progression points as experience, though it need not be a mechanic that in any way resembles experience in a traditional sense). Earned experience is calculated in a variety of ways, determined by the Progression's scope. These go from looking up a stored value to performing exceedingly obtuse calculations. This is why we provide live data in DestinyCharacterProgressionComponent.progressions, so you don't have to worry about those.
steps
Progressions are divided into Steps, which roughly equate to "Levels" in the traditional sense of a Progression. Notably, the last step can be repeated indefinitely if repeatLastStep is true, meaning that the calculation for your level is not as simple as comparing your currentprogress to the max progress of the steps. These and more calculations are done for you if you grab live character progression data, such as in the DestinyCharacterProgressionComponent.
factionHash
If the value exists, this is the hash identifier for the Faction that owns this Progression. This is purely for convenience, if you're looking at a progression and want to know if and who it's related to in terms of Faction Reputation.

Destiny.Definitions.Common.DestinyDisplayPropertiesDefinition

Many Destiny*Definition contracts - the "first order" entities of Destiny that have their own tables in the Manifest Database - also have displayable information. This is the base class for that display information.

Destiny.Definitions.DestinyProgressionDisplayPropertiesDefinition

displayUnitsName
When progressions show your "experience" gained, that bar has units (i.e. "Experience", "Bad Dudes Snuffed Out", whatever). This is the localized string for that unit of measurement.

Destiny.DestinyProgressionScope

There are many Progressions in Destiny (think Character Level, or Reputation). These are the various "Scopes" of Progressions, which affect many things:* Where/if they are stored* How they are calculated* Where they can be used in other game logic

Destiny.Definitions.DestinyProgressionStepDefinition

stepName
Very rarely, Progressions will have localized text describing the Level of the progression. This will be that localized text, if it exists. Otherwise, the standard appears to be to simply show the level numerically.
displayEffectType
This appears to be, when you "level up", whether a visual effect will display and on what entity. See DestinyProgressionStepDisplayEffect for slightly more info.
progressTotal
The total amount of progression points/"experience" you will need to initially reach this step. If this is the last step and the progression is repeating indefinitely (DestinyProgressionDefinition.repeatLastStep),this will also be the progress needed to level it up further by repeating this step again.

Destiny.DestinyItemQuantity

Used in a number of Destiny contracts to return data about an item stack and its quantity. Can optionally return an itemInstanceId if the item is instanced - in which case, the quantity returned will be 1. If it's not... uh, let me know okay? Thanks.
itemInstanceId
If this quantity is referring to a specific instance of an item, this will have the item's instance ID. Normally, this will be null.

Without this, it's not apparent which component identifiers you have to pass in to get those item components.

I'm trying to generate API client library using go-swagger from openapi-2.json, but unfortunately it fails due to non-existing Destiny.HistoricalStats.DestinyLeaderboard definition. Is that something you missed?

Although, please take a look at openapi-2.json validation logs from swagger-codegen-cli tool: https://gist.github.com/Anakros/22fca19844ce82a8082945f9579f3509

The v2 spec requires a type property in the responses > schema object.

So as is this is causing a validation issue:

    <SNIP>
    "responses": {
      "200": {
        "description": "The response for this request.  We don't have documentation for it yet...
        "schema": {
          "properties": {
            "Response": {
              "$ref": "#/definitions/User.GeneralUser"
            }, 
          <SNIP>

I believe what it's asking for is something like this:

    <SNIP>
    "responses": {
      "200": {
        "description": "The response for this request.  We don't have documentation for it yet...
        "schema": {
          "type": "object",
          "properties": {
            "Response": {
              "$ref": "#/definitions/User.GeneralUser"
            }, 
          <SNIP>

Mostly seems like a rogue spacebar. I've fixed what I could find below, sorry the format isn't better, but it should be able to be copy/pasted back into your source.

100:
Profiles is the most basic component, only relevant when calling GetProfile. This returns basic information about the profile, which is almost nothing: a list of characterIds, some information about the last time you logged in, and that most sobering statistic: how long you've played.

101:
Only applicable for GetProfile, this will return information about receipts for refundable vendor items.

102:
Asking for this will get you the profile-level inventories, such as your Vault buckets (yeah, the Vault is really inventory buckets located on your Profile)

103:
This will get you a summary of items on your Profile that we consider to be "currencies", such as Glimmer. I mean, if there's Glimmer in Destiny 2. I didn't say there was Glimmer.

201:
This will get you information about any non-equipped items on the character or character(s) in question, if you're allowed to see it. You have to either be authenticated as that user, or that user must allow anonymous viewing of their non-equipped items in Bungie.Net settings to actually get results.

202:
This will get you information about the progression (faction, experience, etc... "levels") relevant to each character, if you are the currently authenticated user or the user has elected to allow anonymous viewing of its progression info.

203:
This will get you just enough information to be able to render the character in 3D if you have written a 3D rendering library for Destiny Characters, or "borrowed" ours. It's okay, I won't tell anyone if you're using it. I'm no snitch. (actually, we don't care if you use it - go to town)

204:
This will return info about activities that a user can see and gating on it, if you are the currently authenticated user or the user has elected to allow anonymous viewing of its progression info. Note that the data returned by this can be unfortunately problematic and relatively unreliable in some cases. We'll eventually work on making it more consistently reliable.

300:
This will return basic info about instanced items - whether they can be equipped, their tracked status, and some info commonly needed in many places (current damage type, primary stat value, etc)

301:
Items can have Objectives (DestinyObjectiveDefinition) bound to them. If they do, this will return info for items that have such bound objectives.

302:
Items can have perks (DestinyPerkDefinition). If they do, this will return info for what perks are active on items.

304:
Items can have stats, like rate of fire. Asking for this component will return requested item's stats if they have stats.

305:
Items can have sockets, where plugs can be inserted. Asking for this component will return all info relevant to the sockets on items that have them.

306:
Items can have talent grids, though that matters a lot less frequently than it used to. Asking for this component will return all relevant info about activated Nodes and Steps on this talent grid, like the good ol' days.

307:
Items that aren't instanced still have important information you need to know: how much of it you have, the itemHash so you can look up their DestinyInventoryItemDefinition, whether they're locked, etc... Both instanced and non-instanced items will have these properties.

308:
Items that are "Plugs" can be inserted into sockets. This returns statuses about those plugs and why they can/can't be inserted. I hear you giggling, there's nothing funny about inserting plugs. Get your head out of the gutter and pay attention!

500:
Asking for this component will return you the account's Kiosk statuses: that is, what items have been filled out/acquired. But only if you are the currently authenticated user or the user has elected to allow anonymous viewing of its progression info.

In the v3 spec, some Path object Response objects are missing the required Response object "description" property:

For example with /User/GetBungieNetUserById/

    "responses": {
      "200": {
        "$ref": "#/components/responses/User.GeneralUser"
      }
    }

and

"responses": {
  "User.GeneralUser": {
    "content": {
      "application/json": {
        "schema": {
          "properties": {
            "Response": {
              "$ref": "#/components/schemas/User.GeneralUser"
            },
            "ErrorCode": {
              "$ref": "#/components/schemas/Exceptions.PlatformErrorCodes"
            },
            "ThrottleSeconds": {
              "type": "integer",
              "format": "int32"

Another case of rogue spacebars!

Tutorial: 1
One-time milestones that are specifically oriented toward teaching players about new mechanics and gameplay modes.

Weekly: 3
Milestones that repeat/reset on a weekly basis. They need not all reset on the same day or time, but do need to reset weekly to qualify for this type.

Special: 5
Special indicates that the event is not on a daily/weekly cadence, but does occur more than once. For instance, Iron Banner in Destiny 1 or the Dawning were examples of what could be termed "Special" events.

The PgcrImage property is missing /img/destiny_content/pgcr/. Adding that will make the images load properly.

This is not needed for the placeholder images.

Currently you have to pass a characterId, which leads me to make up to 3 requests and then resort all the games by period. Would be great to have one call that just does it.

Per the OpenAPI v3.0 spec posted for Reference objects: "This object cannot be extended with additional properties..."

However this is being done quite a bit in the current spec file version like this example where the x-destiny-component-type-dependency property is in the Reference object.

"DictionaryComponentResponseOfint64AndDestinyCharacterComponent": {
  "properties": {
     "data": {
        "type": "object",
           "additionalProperties": {
              "x-destiny-component-type-dependency": "Characters",
              "$ref": "#/components/schemas/Destiny.Entities.Characters.DestinyCharacterComponent"

The DestinyItemCategoryDefinition returns the wrong category names for weapons.

2 should be Kinetic (is Primary)
3 should be Energy (is Secondary)
4 should be Power (is Heavy)

Might also be happening with other categories, but I haven't checked those.

Where has the list of characters associated with a user's Destiny 1 account moved to?

They used to be in the response from /platform/User/GetBungieAccount/{membershipId}/{membershipType}

Hi!

What is the defined rate limit?

Do rate limits apply to auth/token calls too?
https://www.bungie.net/Platform/app/GetAccessTokensFromCode/
https://www.bungie.net/platform/app/oauth/token/

Thanks!

Also after the Aug 28th changes I am now getting Endpoint not found from the Group ClanMembers endpoint.

So even with a known clan groupId I'm uncertain how to retrieve D1 clan membership information to be able to use that to pull other stats for the clan.

Do you have any guidance on how to retrieve clan membership information for D1 and D2 after the Aug 28th changes?

If I want to get a guardians inventory, in destiny 1 you called the inventory endpoint on a characterId.

For destiny 2, it looks like it's possible to make a getProfile request with CharacterEquipment, CharacterInventories components to get all character inventories in one go?

Now, do I need to have both CharacterInventories and CharacterEquipment to get the full picture? Or will CharacterInventories also have the equipped items.

As of right now, this user has not played Destiny 2. (This will change in about 3 hours)

https://www.bungie.net/Platform/Destiny2/SearchDestinyPlayer/1/G0dly%2023/

Might be worth noting this user did play the beta.

I'm developing an iOS app that uses the Bungie API, and it seems that any native application developed using the Bungie.Net API that requires user authentication would be forced to re-authenticate users every hour.

Reading Bungie.Net API's OAuth Documentation, I am supposed to select an OAuth Client Type for my application "as described in section 2.1 of the OAuth 2.0 specification." RFC 6749 clearly states that "A native application is a public client installed and executed on the device used by the resource owner." Then, I also see back in your OAuth documentation that "A public client differs from a confidential client in that... it will not receive a refresh token in response to a token request." So, if I'm reading this correctly, any native app will have to re-authenticate the user every hour, which is obviously not ideal.

Am I misinterpreting the documentation? Could a native app be considered a confidential client if the API Key is stored in the application binary in an encrypted format and any transient tokens are stored in the OS's secure storage, such as iOS's Keychain? If not, would you consider providing public clients refresh tokens?

Destiny in-game has larger icons for gear now the game is 4K. The API still provides icons at the Destiny 1 size. Now phone screens are so highres people have started to comment the icons look blurry. It would be great if it was possible to get higher res versions of the icons.

I'm trying to get OAuth up and running using a public client type, I get my authorization code from the Authorization endpoint but when trying to send a request to the Token endpoint I always get a "400 - Cannot parse client_id".

I am setting client_id, grant_type, and code in the body of my POST request with "application/x-www-form-urlencoded" as the Content-Type. Can anyone point me in the right direction here?

While there are ways to track the status of services and stuff within the APIs, it is not really well documented and should be something everyone is briefed on when they start using the APIs. Whether this is just a matter of better documentation or whether there needs to be a dedicated endpoint with a simplified response structure is something we need to figure out.

All other instances of schemas with the "items" property explicitly specifies a type of "array". Not sure if this is a required thing or not but its the only one I've come across.

Heyo, quick question about how the Browser Based Apps are supposed to work.

I assumed that If I filled out this section on https://www.bungie.net/en/Application/:

waited some time, then tried to hit an endpoint via browser only (no proxy), I'd be able to get data back.

However, I am still getting blocked:

Am I doing something wrong? is this functionality just not ready yet?

Thanks!

I'm moving my question over from the Bungie group per your post:

My D1 "Clan Leaderboards" app is currently broken because I can't figure out how to retrieve a user's clan groupId after these changes.

• The old method of /User/GetBungieAccount/ no longer returns the clans block.
• The earlier recommended method of /Groups/MyClans/ returns Endpoint not found.

I looked at the new D2 spec and see endpoints that require the clan groupId but don't see what provides it. So now I'm stuck. I don't know how to get the clan groupId that is required for the Clan Leaderboards endpoint for either D1 or D2

Can you provide some direction on how to get the clan groupId for D1 and D2 after the Aug 28 changes?

I think this is something I think has been in the APIs since D1, but now that we are all official and all, might be worth naming these to match in-game before anyone starts using them. :)

There might be other Enums that are still using internal development names that while most of us know what they are, other might go whaat? New item level!!

This is a suggestion to add some kind of default/sample value property. When I iterate through a data structure to build a sample json I by default set strings to "" and numbers to 0 but there are instances where having like an example value would be useful such as with definition hashes, image urls and date time strings.

The following issue has spun up into a separate subject that's worth addressing:

#6

Right now, Swagger doesn't seem to have good conventions for relaying information about generics: info that would be useful for developers.

The current proposal is that we add metadata about generic properties - which would also imply that we should add schema for the base generic classes.

I'm not opposed to this idea, though I don't know if we'll have time to do it before launch.

Please discuss here: and if you have insight into the OpenAPI spec that you'd like to share for common patterns of addressing information such as generics (or if you just have an opinion about how you'd like this data to be conveyed), lay them on us!

Currently, the generator is doing the dumb thing when it comes to conveying properties of classes that are inherited from base classes. It puts the property on the child class itself, rather than having a oneOf (or even allOf) relationship to a parent class.

Retaining the base class relationships would be great for a code generator, even if it makes the HTML documentation a bit more obtuse (or the HTML generator a little more recursive). I believe it'd certainly be worth it to have this improvement.

Thoughts? Suggestions? Again, this is another one that I don't know if I'll have time for before the game comes out. But I think it could come in handy.