Two suggestions to make custom commands/APIs work better


First suggestion is something like customTFapi

similar to customapi but it checks the first character for a 0 or 1

if 0 (false) it displays the output similar to customapi, but it doesn’t remove points (command cost) or set cooldown for the user

if 1 (true) it displays the output, and removes the points from the user, as well as setting the cooldown.

Second suggestion is to allow updating the DB via “HTTP API SQLite Access”

It’s pretty pointless just being able to query the DB and not actually do anything to the data.


You can use a custom script to accomplish what you’re asking. At this time I’m pretty sure customapi is supposed to just return the text result from a url (or ‘api’). customapijson does similar but it expects the result to be in a json format.


Did you search the forums? We already have a solution for reading, and writing to the database that is a much more secure option. Read this article for more information.

Like UsernamesSuck said, the customapi implementation is designed to be a simple option for a simple solution, you should be using a custom script for what you’re looking for.


this would help open it up to scripts being written in any language

and what is the point of the http api for sqlite if it’s read only and you can do the same thing with the web panel API (which isn’t the easiest to use)?

edit: nvm, just saw you can use MySQL instead.


Actually PhantomBot scripts have to be written in JS because we use Rhino. The websocket api we have for the panel is a secure method for allowing outside programs to interact with the bot.

I believe a decent bit of the reasoning is due to how the bot accesses the database, and to preserve our read/write queue. You’d have to wait for IO or Scania to chime in for a more detailed answer behind the logic.


There are write methods (update and delete), please review the documentation.

You can choose to use MySQL or the default of SQLite3. There is also an unsupported feature to use H2 that we have been testing and playing with internally.

The API can be used as it is REST calls rather than WebSockets. Some folks prefer REST calls for simple interaction rather than setting up WebSockets. The Panel uses WebSockets to keep a connection open for transmitting data rather than calling several REST calls. Anyone can use the WebSockets interface if they want as well.


“Four query API calls are provided as part of the SQLite Access API. The calls all return JSON formatted data for easy processing.”

No mention of write methods here