Request/ Response Format
JSON is used for the request and response format. JSON is a lightweight and portable format that maintains human-readability.
When making POST or PUT requests, the request parameters MUST be JSON-encoded and placed in the request body. When making GET requests, the request parameters MUST be JSON-encoded, then URI-encoded and placed directly in the query string.
Clients should expect JSON-encoded responses for every request, even those that result in an error. The only exception is when uploading files using the S3 endpoints and the file is bigger than 2mb - you will receive a 413 error from Nginx.
Each method defines the HTTP method required depending on what the usage is. For example, if the method is used to simply get data, the HTTP method would be GET. If the method is used to delete data, it uses DELETE.
Date / Time Format
The date and time MUST be expressed in RFC 3339 format: YYYY-MM-DDThh:mm:ssZ
Bracketed IDs ("[id]"s)
Whenever a bracketed ID ("[id]") appears in a method's name or URL (e.g. "GET /containers/[id]" or "https://cms-api.phunware.com/v2.0/containers/[id]"), treat it as a placeholder for the ID number of the item involved in the method (in this case, "GET /containers/58b72e03472f3f601810858f" or "http://cms-api.phunware.com/v1.0/containers/58b72e03472f3f601810858f").
Whenever an ellipsis ("…") appears in the JSON body, treat it as a placeholder for additional instances of the data that immediately precedes it.
PUT Methods & Partial Updates
There are a few differences in how the request parameters get handled by PUT methods:
GET Methods & Query Strings
The GET methods outlined in this document will use query strings, not JSON bodies, when making a request to a URL. This requires the user to convert JSON into a URL-encoded query string.
Minified fragment using http://bigaqua.org/minify_json.html
URL-encoded, minified fragment using http://www.url-encode-decode.com/
URL-encoded, minified fragment as the query string.
In order to compose a request, a "?" is appended to the end of the request URL, then the URL-encoded, minified fragment is added.
Setting the Header
In order to provide Phunware APIs with the JWT, you must provide a header named Authorization and the token must be prefixed with the word Bearer.
The following endpoints do not require a JWT to be supplied.
HTTP Status Codes
Each successful response will include a JSON payload and the success code number.
Used when the clone process has been started successfully. The clone process will continue running in the background after the response is returned so it does not block the client.
Each failed response will include a JSON payload that includes the error code number and message:
The actual message for this "Bad Request" error will vary depending on whether the error was caused by bad data sent in the request, a validation error when validating the request data or any other generic request error.
Used when the operation fails authorization checks.
The actual message for this "Unauthorized" error will vary.
Used when the operation fails security checks (e.g. wrong app ID specified as input to retrieve specific data).
The actual message for this "Forbidden" error will vary.
Used when the requested resource does not exist (e.g. cloned container).
The actual message for this "Not Found" error will vary depending on what could not be found.
Used when a clone process is in progress. Only one clone process can be started for a given organization.
The actual message for this error will vary. When attempting to clone a container that is already being cloned, for example, the following message would be returned:
Internal Server Error
The actual message for this "Internal Server Error" error will vary. For a failed container clone, for example, the following message would be returned: