DevLounge APIs

On these pages you will find general information about all APIs used in the Devlounge and how they are put to use. Please be aware of the fact that to integrate your game with Bigpoint, basic programming knowledge is required. Additionally you might want to familiarize yourself with the XML-RPC or JSON-RPC specifications.

Table of Contens

General API Information

While integrating your game you will come across a set of 3 different APIs in use at the Devlounge. Using the Game-API, you will setup a communication-gateway for the Bigpoint portal to communicate with your game. The Portal-API on the other hand allows you to call at the Bigpoint portal, containing several tools at your disposal to enhance the way you interact with users coming from Bigpoint.

Last but not least you will encounter the Payment-API, which enables you to harness the full power of Bigpoint's own payment system, boasting hardened security using SSL, at least 120 available payment methods and Bigpoint's own experience in the field.


To use these APIs, you need to note the different URLs in use at the Devlounge. The Game-Api and the Portal-Api are capable of handling JSON-RPC as well as XML-RPC. The Payment-URL can only handle XML-RPC at present.

Here's a list of all available URLs:

Important: Please be aware that you will need to switch the URLs in use at your game as soon as it is put into “live”-status. The Sandbox-URLs will cease to work, as the Live-URLs will be used from then on. At the same time, you will only be able to send requests to Bigpoint's live-URLs.

Common and Recurring Parameters

Even though each method will need a changing number of parameters, some of these will reappear with nearly every method in use at the Devlounge. These common parameters are explained in the following table, each with their own explanation:

Name of parameter Type Description
partnerID Integer This is the partner-ID assigned to your account when you registered at the DevLounge.
projectID Integer This is the project-ID assigned to your current project. Note that this ID will change for each new instance of your game and after it has been put into live.
userID Integer A numerical representation of an user in your game. This ID is assigned during the registration-process in your game.
bpUserID Integer A numerical representation of an user from Bigpoint's portal. This ID is assigned during the registration-process at the Bigpoint portal and will be different from the userID as used in your game.
affiliateID Integer A numerical represnation of an affiliate-partner of Bigpoint's. This way marketing-efforts and their conversion rates can be tracked.
authTimestamp Double A unix-timestamp containing the current number of milliseconds since the begin of the UNIX epoch (1/1/1970).
authHash String A generated hash-value used to authenticate requests sent to and from the Devlounge. The creation of this hash is explained in the next chapter of the wiki.


To authenticate all incoming requests, a set of two different secret-keys is used to generate a unique hash for each transmission. These secret-keys are only known to Bigpoint and a partner and should be kept secret on your side.

Whenever a transmission takes place, the secret-key is appended to the raw request send to either side, with the resulting string being hashed again using the MD5-algorithm. Next, the request is send, containing the JSON- or XML-request-body as POST-data and the generated hash as a GET-parameter called “authHash”:

Pseudocode (JSON):

authHash = generateHash(
   {"jsonrpc": "2.0", "method": "someMethod", "params": [42, 23], "id": 1}2291f5d0cdf0b6f20f0a15884d2b6733

Important: To avoid mismatches of generated hashes on your side and Bigpoint's, please make sure that the request itself and the hash contain lowercase letters only.

As soon as you receive a request via your API-endpoint, authenticate the request using the sent authHash by repeating the hash-process as described above on your side, finally comparing the hash generated by your systems and the one sent with the request. Here is a code snippet written in PHP as an example of how such an authentication could be implemented:

    $sHash  = strtolower(md5($sXml . $sSecretKey));
    if (strcmp($sHash, $_GET['authHash']) != 0) {
       // error handling

As you can see from the example, the secret-keys is appended directly to the request-body (no matter if it's encapsuled in JSON or XML) and then sent to the hashing algorithm.

Important: Bigpoint's infrastructure is based on PHP - thus all hashes are created using PHP's own “md5”-method with UTF-8 encoding. If you are not using UTF-8 or a different implementation of the MD5-algorithm, mismatches might occur. Please check your own hashing method compared to the one in PHP to find a possible solution for your mismatches.


The Game-API contains methods called by Bigpoint in your game. Currently, only 4 methods are needed to integrate your game:

For more details, please click on one of the above methods or head to the Game-API wiki page.


The Portal-API supplies you with a number of methods that can be called on Bigpoint's side, such as sending an e-mail to one of your users, deleting inactive game-accounts and more:

For more details, please click on one of the above methods or head to the Portal-API wiki page.


To use Bigpoint's payment system, you will need to integrate a small set of methods that our payment will call in your game. These are usually called after an user has finished his transaction or cancelled a previous order. Here is a list of all calls used by the payment system:

Important: Please note that the Payment-URL can only handle XML-RPC at present!

For more details, please click on one of the above methods or head to the Payment-API wiki page.

en/apis/general.txt · Last modified: 2018/02/27 15:15 (external edit) Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0