API Prerequisites
After generating your API token you are ready to start making API calls and communicating with our service. We recommend reading this page before starting and understanding limitations of our service as well as what is to be expected. We will also outline some useful methods and tools that should assist you with making our API service work with your usage.
Methods
- POST
- GET
We make use of POST and GET calls for our API services. If you are unfamiliar with what POST and GET is then we recommend reading this resource and getting more familiarized with them. The reason for the two different usages are as follows.
Our service makes use of POST calls to insert new records, or to return back records based on a filtered query. For example you can use our app-create API call to create a new application record on DEVSEY. In that situation you would POST the application URL as a string. We also use POST for filtered queries, for example you could make use of the report-view-by-id API to view a specific report by application ID.
Our service makes use of GET calls to return lists. Some of our filtered queries have acceptable values. Our GET APIs will return those lists that you can make use of. They do not require any additional input or filtering; they are just the full list. Therefore, they do not require any submitted information from your application. For example, when you make a call to our app-view API it will return all of your applications that are stored on DEVSEY. It already knows which applications belong to you based on your API Token, therefore nothing needs to be submitted for this return.
Return
- JSON (JavaScript Object Notation)
- SUCCESS: 200 or 201 or 202
- ERROR: 400 or 404 or 403 or 500
Our service returns back JSON (JavaScript Object Notation). If you are unfamiliar with JSON we recommend reading this resource and better familiarizing yourself with it. In short JSON is similar to an array; there are keys and there are values. As you go through the documentation for each API service we will define what each key is and the data type to expect as the value. It is up to you and your application on how you decide to parse that information. Many languages have built in functions for decoding it, and looping through it. For example PHP has json_decode / json_encode. Depending on what language your application is written in, I would check the documentation for that language. Below is an example of a JSON return from DEVSEY, upon a successful call this is the type of return to expect.
In the event of a successful RETURN you should expect back an HTTP status code of 200 or in some cases 201 or 202. It is not necessarily required for you to understand what all the HTTP status codes are but they do assist in making a fully functional application. If you are unfamiliar with HTTP status codes we recommend reading this resource.
Failed calls or returns will most likely show 400, 404, 405, or 500. If you receive one of these error codes back it doesn't necessarily mean that your code is incorrect. It is possible that our service or API service is down for the moment. Before evaluating your code for mistakes we do recommend checking our status page first. If you scroll to the bottom you can check our real time status graph to determine if our site services are up or down.
If our service is currently up and running and you are getting failed returns, then we recommend validating that you have the correct information required in the call, and that there are no mistakes in your application code.
Code Language
We do not have any restrictions for coding languages. As long as your application can make POST and GET calls, and receive JSON back. It is important to note that whatever language you choose should also be able to pass HEADERS with the request call. Our API service makes use of the Authorization header for your API Tokens, and the Accept header for application/json.
There are plenty of coding languages to choose from and because of that we unfortunately cannot assist you with writing your application or calls. Any examples we provide will most likely be in a singular language.
Headers
Our application makes use of two headers when making a POST or GET call. We use Authorization and Accept. Authorization must be followed by your API Token. Accept must be followed by application/json.
Testing Resources
We recommend Postman. Postman has both paid and free services for allowing you to test your API GET and POST calls to our service. This is not required but it can make the process easier to test our calls before implementing them into your project.
