There is no easy way to reproduce what you may have experienced while using GameSparks manage-screens. There are no other platforms which provide an alternative to this feature, though most do offer some sort of player-manager in their portals. So we will instead need to discuss what other possibilities there are to migrate or reproduce them.

On the subject of player-managers, we have provided a topic on player managers and how each alternative platform deals with their own if you want to check that out.

REST API Endpoints

The first obstacle you have is converting the JS from the manage-screen IDE into a set of REST APIs. There is no way to re-use the Spark API code unless you are planning to reproduce the Spark API on your own service, so the best approach is to rewrite the manage-screen code using the Cloud-Code offered by a destination platform.

Using the destination platform, you can create new custom endpoints or microservices calls and treat them like GameSparks callbacks scripts. These endpoints will act as an interface between the webpage hosting the new screens and the destination platform’s APIs.

If there is no Cloud-Code alternative for the destination platform it may be possible to reproduce some of your previous functionality using the native REST API of the platform, or by replicating your custom-code in a Lambda function using AWS API Gateway as a connection between your website and the Lambda.

Keep in mind that this process usually cannot be started until the majority of important APIs are reproduced on the new platform, so you might be forced to approach manage-screens later in the migration. However, you don't need to have the UI ready to start this process and these APIs could be set up and tested using something simple like Postman to test the API well before migrating the UI has started.

Reproducing UI & Forms

Migrating the HTML for manage-screens will be more straightforward than reproducing your snippets Cloud-Code. Although GameSparks does have some custom-tags in their HTML editor, in most cases the HTML is used for simple CRUD forms which are easily reproduced in raw-HTML and in some cases you will be able to achieve more without GameSparks tags as well as being able to find more examples online on how to reproduce the same forms.

Unfortunately there is no quick way to do this. Copy/pasting your existing HTML from GameSparks will save you time, but you won't find replacement for any GameSparks-specific tags so it could be faster starting from scratch.

There are a lot of form generator tools out there which will allow you to recreate your GameSparks HTML from simple templates or drag-drop interfaces. Most of them aren't too complex, but some of the simpler ones will allow you to get the raw HTML from the forms you put together which would allow you to copy/paste that HTML into your own website to speed up the process of rewriting all your forms from scratch.

Alternative Services & Solutions

There are other services such as which are already being employed by GameSparks customers as an alternative to GameSparks manage-screens.


Retool is a variation of the form builders mentioned above, but it also hosts the forms for you and allows you to connect the forms to your own APIs without need to spend extra time programming those connections into the frontend.

You can also hook retool directly up to a mongoDB instance if your destination platform gives you access to your own database. This would be nice to replicate a flow for something like metacollections for example.

There are already a number of GameSparks customers which have migrated from manage-screens to Retool successfully so we recommend checking it out.

Google Sheets

Google Sheets is also a good replacement for GameSparks manage screens. Using a google-script you can add additional functionality to sync your sheets with the destination platform in order to update content or functionality you control through the manage-screens. In cases where you need something more robust than google-sheets in order to parse data or add data to a database you can use a combination of API Gateway and Lambda functions.

One benefit to Google Sheets is that it is free and easy to use, though configuring those docs so they can be formatted into noSQL or SQL structures would take some learning. Beamable has a guide on how to set this flow up with their platform using their content service (an alternative to something like GameSparks’ Metacollections).

Something to note about Google-Sheets and this approach is that, for very large collections or very complex pages with multiple tabs, these scripts can get very slow as you add to them. However, for something under a few thousand records there will be no problem.


With GameSparks manage-screens you needed to be logged into the portal in order to view your screens. Through your game’s permission management and group management you could control which screens different users were allowed to view.

If you are going with your own system or an alternative form-builder like retool you will need to be aware that no security is going to be set up between the destination platform and your new forms. You will therefore need to be aware of any requirements for REST communications and permissions.


AccelByte has a very robust access management system with accompanying APIs. As an admin you will need to acquire a Grant Token before being able to interact with their REST services. This includes some basic-auth headers which include the username and password of your account.


Beamable also requires an auth-token to be granted before you can communicate with their REST APIs, however, their Microservices can also be hit from a HTTP request which means that if you plan on rebuilding your manage-screen APIs in a microservice, anyone who finds the URL can execute your code. There are some ways to prevent this with API Gateway mentioned below.


If you intend to go down the route of creating your own web-pages for your new custom manage- screens you will need to think about hosting them somewhere.

In most cases these pages will be essentially static web-pages so an AWS service like S3 is a good option. However, you will likely need something more complicated if you need to handle authentication and parsing so in this case AWS has services like Amplify and Lightsail which can be used to easily deploy and host web-apps so we would encourage you to check those out.