pufferd
The PufferPanel and pufferd APIs both use the OAuth2 specification for allowing applications to authenticate with the API and for permission control.
OAuth2 differs from other authentication methods in that you first are required to get an “access token” (AT) in order to perform any actions against an API. This AT is issued from the “authentication server” who’s job is to validate the authenticity of the credentials and to grant an AT that allows for certain privileges. This AT is then given to the APIs which validate the AT and then perform the action requested.
In the case of PufferPanel, the authentication server is the panel itself, which exposes the “Auth” endpoint. This endpoint MUST be called first in order to get the access token. A description of how to use this endpoint is located here: Auth
Authentication
Authenticate with the panel to get an access token, which is used to authenticate with the remainder of the API.
Request parameters
Method of authentication to use
Use a client_id and client_secret to authenticate
Use a username and password to authenticate
The client_id to authenticate with. REQUIRED when grant_type is client_credentials.
The secret key for the client_id. REQUIRED when grant_type is client_credentials.
Username of account. REQUIRED when grant_type is password.
Password for account. REQUIRED when grant_type is password.
Responses
This response is given to signify the request was processed and the credentials provided were correct.
Body
The access token to be sent to authenticate with the rest of the API
The time this token expires
The type of token issued. This will always be bearer.
The scopes this access token will grant, space delimited
This is returned when the client sends an invalid request, generally due to missing or invalid data
Body
Reason why request failed
Calls which are specific to control the daemon
{id}{id}{id}{id}{id}/reload{id}/start{id}/stop{id}/stats{id}Authentication
DO NOT CALL THIS METHOD DIRECTLY, AS THIS WILL NOT REGISTER THE OPERATION IN THE PANEL
Creates a server, using the body to populate the data values in the template. Note, any keys specified that do not exist in the template will still be added to the server’s data file.
Name indicates the human-readable name for the server. Type indicates the template name the server should be created with.
Path variables
Server’s unique identifier (UUID)
Examples
PUT /server/12345678-1234-1234-1234-123456789012 HTTP/1.1
Content-Type: application/json
{
"name": "mytestserver",
"type": "minecraft"
"memory": "1024",
"jar": "server.jar"
}{id}Authentication
This edits the data for a server. The syntax follows the Create Server function call. All values are explicitly set, there is no way to remove or reset a value. Only fields passed in will be updated.
Path variables
{id}/reloadAuthentication
Reloads the data objects for the server from the server’s data file. This will not restart the server, only refresh the in-memory settings. Restarting the server or other operations will have the newly reloaded data.
Path variables
Server UUID
{id}/statsAuthentication
Gets memory and CPU stats for a server. This does not work with docker-ran servers. CPU is the percentage of CPU time used (similar to htop) and memory is the RSS value.