Full Guide Using the API

This section will serve as a brief guide on how to use the FWGL Developer's API.

About My API Key

An API Key is required to access data using the Fantasy WGL API. You can read about how to obtain an API Key on the Getting Started page.

Currently, the following restrictions are in place on API Keys

• Each user is only allowed a single API key per Wargaming OpenID account during this stage of development. This may change in the future based on necessity.
• Each key will be restricted to the following IP addresses:
  • Server IP - This is the IP address of the environment which will run your application. Currently only a fixed IP address is allowed, and only one IP address is able to be used for this field.
  • Personal IP - In order to make things a little bit easier for developers, their own IP will be allowed for creating requests locally. By default, this will be the address you created they key from, however you can update it any time on the API Key management page.

Usage Limit

In order to ensure stability for all users, there is a limit on the number of requests that can be made per minute. By default, this limit is currently 200 requests per minute. This value may be altered in the future based on server performance results.

If your project requires a higher limit, you can request a limit increase with Fantasy WGL support. See the help page for more information. Please include as much information in your request as possible as to why you require a higher limit.

API Changes

As development continues on the FWGL Developer's API, some changes to both requests and responses may be made. While changes will be made downwards compatible as often as possible, there will be some times where "breaking changes" will occur.

Downwards Compatible Changes

Downwards (or Backwards) compatible changes are changes that will not affect your project's current functionality in any way. These changes will often be improvements to current functionality or new functionality to the API. These changes will be listed on the Release Notes page as they become available for use.

Downwards Compatible changes may include:

• Addition of a new request
• Addition of a new optional parameter to an existing request
• Addition of a new field in the response of an existing request
• Changes to the order of fields in the response of an existing request

Breaking Changes

Breaking changes will be listed on the Deprecations page as far in advances as possible, with a minimum notice of one month. It is every developer's own responsibility to monitor for any upcoming changes to ensure continued functionality of their projects.

Breaking changes may include:

• Deletion of any listed request
• Addition of a new required parameter to an existing request
• Changes to a response field type
• Removal of a response field