API v2 is an incremental improvement over API v1, meaning it includes new features, additional endpoints, and more efficient data handling while minimizing architectural changes.
API v2 is designed following REST principles, meaning:
However, Installatron continues to maintain and support API v1:
Whether API v2 is adopted fully or partially, or if API v1 remains in use, the updated documentation -- accessible from the menu on the side of this page -- offers detailed information on each API endpoint, including parameters, responses, and error handling.
Whereas API v1 accepted a cmd input parameter, API v2 endpoints now use REST principles.
For ease of adoption, you may continue to use existing API v1 cmd values by defining a X-API-Version: 2.0 header or api_version=2.0 parameter in the query string. This will not require modifying the HTTP request method or HTTP endpoint.
Applications | ||
| cmd=browser | → | GET /browser |
| cmd=install | → | POST /browser/{id}/install |
| cmd=import | → | POST /browser/{id}/import |
| cmd=migrate | → | POST /browser/{id}/migrate |
Installs | ||
| cmd=installs | → | GET /installs |
| cmd=edit id={id} | → | POST /installs/{id} |
| cmd=update id={id} | → | POST /installs/{id}/update |
| cmd=backup id={id} | → | POST /installs/{id}/backup |
| cmd=template id={id} | → | POST /installs/{id}/template |
| cmd=clone id={id} | → | POST /installs/{id}/clone |
| cmd=sync id={id} | → | POST /installs/{id}/sync |
| cmd=createadminsso id={id} | → | POST /installs/{id}/login |
| cmd=detach id={id} | → | POST /installs/{id}/detach |
| cmd=uninstall id={id} | → | DELETE /installs/{id} |
WordPress: Plugins | ||
| cmd=edit id={id} list-plugins=1 | → | GET /installs/{id}/plugins |
| cmd=edit id={id} install-plugin={id} | → | POST /installs/{id}/plugins/{id} |
| cmd=edit id={id} activate-plugin={id} | → | POST /installs/{id}/plugins/{id} activated=true |
| cmd=edit id={id} deactivate-plugin={id} | → | POST /installs/{id}/plugins/{id} activated=false |
| cmd=edit id={id} auotup-plugin={id} | → | POST /installs/{id}/plugins/{id} autoup=all |
| cmd=edit id={id} noautoup-plugin={id} | → | POST /installs/{id}/plugins/{id} autoup=none |
| cmd=edit id={id} uninstall-plugin={id} | → | DELETE /installs/{id}/plugins/{id} |
WordPress: Themes | ||
| cmd=edit id={id} list-themes=1 | → | GET /installs/{id}/themes |
| cmd=edit id={id} install-theme={id} | → | POST /installs/{id}/themes/{id} |
| cmd=edit id={id} activate-theme={id} | → | POST /installs/{id}/themes/{id} activated=true |
| cmd=edit id={id} deactivate-theme={id} | → | POST /installs/{id}/themes/{id} activated=false |
| cmd=edit id={id} auotup-theme={id} | → | POST /installs/{id}/themes/{id} autoup=all |
| cmd=edit id={id} noautoup-theme={id} | → | POST /installs/{id}/themes/{id} autoup=none |
| cmd=edit id={id} uninstall-theme ={id} | → | DELETE /installs/{id}/themes/{id} |
Backups | ||
| cmd=backups | → | GET /backups |
| cmd=editbackup id={id} | → | POST /backups/{id} |
| cmd=restore id={id} | → | POST /backups/{id}/restore |
| cmd=restoreto id={id} | → | POST /backups/{id}/restoreto |
| cmd=delete id={id} | → | DELETE /backups/{id} |
Templates | ||
| cmd=templates | → | GET /templates |
| cmd=edittemplate id={id} | → | POST /templates/{id} |
| cmd=deletetemplate id={id} | → | DELETE /templates/{id} |
Users | ||
| cmd=users | → | GET /users |
| cmd=edituser user={id} | → | POST /users/{id} |
| cmd=guixfer user={id} | → | POST /users/{id}/login |
| cmd=deleteuser user={id} | → | DELETE /users/{id} |
Logs | ||
| cmd=logs | → | GET /logs |
No changes are required for Users and Websites management when updating to API v2 from API v1.
API v2 follows a new best practice by consolidating the definition of Users and Websites under the Users API endpoint, whereas API v1 accepts a websites and user input parameter with any API request.
API v2 continues to provide the result, errcode and message response members which uniquely identify whether and specifically which error has occurred. This works exactly as API v1 does.
API v2 extends this behavior by exposing conventional HTTP response codes to indicate the success or failure of an API request.
Generally speaking, response codes in the 2xx range signify a successful request. Codes in the 4xx range indicate failures triggered by the given the information, such as missing required parameters. Meanwhile, codes in the 5xx range represent errors on Installatron's side, though these are uncommon.
If you are already using the result, errcode and/or message to determine the success or failure of an API request, there is no necessity to implement handling of HTTP response codes.
API v2 implements limited adjustments to the data response member, which is returned by the Installs API and other APIs such as Backup, Template, Clone, Sync, Restore, Restore To, Import, and Migrate.
These adjustments were implemented to eliminate inconsistencies in member names used to represent the same information across both read (GET) and write (POST) calls within these APIs.
You may utilize API v2 Requests while maintaining API v1 data structure. To do this, when updating the requests also include a X-API-Version: 1.0 header or api_version=1.0 parameter in the query string.
Otherwise, the data response includes these member name changes:
/installs, /backups, and /templates | ||
| list-files | → | files |
| list-exclude-files | → | exclude_files |
| list-tables | → | tables |
| url-domain | → | url_domain |
| installer | → | application |
| autoup-backup | → | autoup_backup |
| autoup-plugins | → | autoup_plugins |
| autoup-themes | → | autoup_themes |
| autobk-daily | → | autobk_daily |
| autobk-weekly | → | autobk_weekly |
| autobk-monthly | → | autobk_monthly |
| list-plugins | → | plugins` |
| list-themes | → | themes |
| list-notification | → | notification |
| path-created | → | path_created |
| db-host | → | db_host |
| db-type | → | db_type |
| db-name | → | db_name |
| db-user | → | db_user |
| db-pass | → | db_pass |
| db-prefix | → | db_prefix |
| version-updates-available | → | version_updates_available |
| cf-login | → | login |
| cf-email | → | |
| cf-sitetitle | → | sitetitle |
| cf-sitetagline | → | sitetagline |
| cf-twofactor | → | twofactor |
| cf-limitloginattempts | → | limitloginattempts |
| cache-tables | → | cache_tables |
| cache-files | → | cache_files |
| cache-time | → | cache_time |
| cache-numbackups | → | cache_numbackups |
| cache-preview | → | cache_preview |
| link-admin | → | link_admin |
| time | → | time_created |
| time-updated | → | time_updated |
| version-autouped | → | version_autouped |
| version-autouped-attempts | → | version_autouped_attempts |
| version-available | → | version_available |
In addition, certain members have modified return values:
The data response includes these member name changes:
| appid | → | id |
| link_changelog | → | links[changelog] |
| link_site | → | links[site] |
| link_demo | → | links[demo] |
| link_showcase | → | links[showcase] |
| link_support | → | links[support] |
| link_docs | → | links[docs] |
In addition, certain members have modified return values: