This is the first one I've generated too so I'm still a little bit lost. I'll endeavour to find out how to do that though. Also, how I was planning to organise all the endpoints was as such: 1. With a given URI pointing to an endpoint, give it a name (ie. GetDestinyAccount) and create a new page with that name 2. Fill out the Endpoint template in the source similar to the following for GetDestinyAccount to make it pretty:[quote]{{Endpoint | uri = /Destiny/{membershipType}/Account/{destinyMembershipId}/ | method = get | accessibility = public | description = Returns Destiny account information for the supplied membership. | name1 = definitions | desc1 = If False, will not return definition information. Appended as a querystring parameter. | name2 = membershipType | desc2 = A valid non-BungieNet membership type. | name3 = destinyMembershipId | desc3 = Destiny membership ID. | requestExample = https://www.bungie.net/platform/Destiny/2/Account/4611686018429501017/ | responseExample = <syntaxhighlight lang="javascript">JSON HERE</syntaxhighighlight> }}[/quote] 3. The template itself adds the "Endpoint" category, and based on the accessibility adds another category - either PublicEndpoint or PrivateEndpoint. So you should be able to open up the category page for Endpoint to view all of them, or PublicEndpoint to view just public ones and so on. You then also add in another category for the type of endpoint it is. For example, that one relates to Destiny (based on the first part of the path) so it gets added to the Destiny category. That's how I think we should do for the others, too (ie. User, Message, etc...). I also think it would be handy to create an Enum-type template page for each of those objects in the Globals page you've added in. The reason for that is so when we generate pages which take URI parameters (like the GetDestinyAccount one), we can just link to the membershipType page rather than having to update each individual endpoint page which uses them.