SeAT has a REST API. Endpoints are protected by an access token that is limited by IP address. For every IP address that wants to make API requests to SeAT, a unique token is required. API Tokens have no concept of ACL's. The API should primarily be used for integrations with other systems.
Currently, all API endpoints live at
<seat url>/api/<version> where
<seat url> is the full url to your SeAT instance and
<version> is the API version you wish to interact with.
Since SeAT 3.0, API documentation is generated from source code annotations and presented via a Swagger UI. As a result, endpoint documentation is now directly available on your instance at the following address
<seat url>/api/documentation. A link to the documentation is also provided on the API key management page available to users with the Superuser role.
If you get an error when viewing the API documentation that complains about a file called
api-docs.json, make sure that you ran the
php artisan l5-swagger:generate command as part of the installation and upgrade routines.
Authentication to the SeAT API is done via a
X-Token header. A token may be obtained by browsing to the API settings page in the SeAT WebUI and generating one. A sample request using
curl with an authentication token can be seen below:
Make sure you specify the Accepted content-type header as
application/json. When using
cURL, you can specify it with
If you don't do this, the API will respond with a redirect and not give you the expected content.
All SeAT API responses will include the appropriate HTTP response codes. You should check this for error handling purposes. Some sample response codes could be:
|200||OK||The request was successful.|
|404||Not Found||The requested endpoint could not be found.|
|422||Unprocessable Entity||Typically, input validation has failed. The response json should contain the errors.|
|500||Internal Server Error||Something bad has happened. Check the server and Laravel log files for more details.|