In this training we'll discuss important elements that you'll need to consider in order to begin creating/testing your own API calls using requests found in our API Dev Portal (https://dev.scout.systems).
API List
We're going to make the assumption that if you've been tasked with setting up API functionality between your own internal systems and the data available from Scout Systems, that you've got a basic understanding of REST API's GETs/POSTs (as well as PUTs and DELs). These requests are all listed in the left hand column when visiting https://dev.scout.systems/apis and selecting the version you wish to work from (for most it'll be the latest one available).
There are dozens of potential requests that can be made - ranging from Step Instruction responses, to machine status data, to maintenance requests, as well as data and control elements related to Stations/Units/Work Orders. But before you can even begin, you're going to need to generate a JSON Web Token (JWT) in order to securely communicate between your system and ours.
Generating a Token
To do so, you will need to make a 'Token' POST, passing through the username and password from your HQ User account that was granted API permissions (this was covered in the previous training materials if you need to review). Please note this is NOT necessarily your API Portal logins.
Along with the table view above, all calls can also show you the raw schema view for the same request if you prefer.
For security purposes the token authentication expires every 30 minutes. We have developed a separate 'Renew Token' POST you can use, allowing you to "refresh" your token. For our customers who need to regularly push/pull data this is a must-use request. But if you only periodically make calls (perhaps 1-2x per day, or less frequently), this may not be necessary.
Making a GET Request
Perhaps you need to see what station is building a particular unit for a customer. Or you need to know which of your Operators are completing a work order. Or perhaps you just want to know the status of a work order. To do so, you will need to make the request: 'Work Order' GET. But you'll quickly realize that to do so, you're going to need to pass in the {id} for the work order you wish to get more information on. This means you must first find the corresponding ID. You can do this in multiple ways:
- 'Work Order Search' GET - if you know the approximate date range you wish to search (perhaps all of last week), you can pass through request parameters {StartDate} and {EndDate} to narrow your search for a particular Work Order.
- 'Work Orders In-Progress' GET - if you know the job is still being worked on AND you already know the station ID where it's being built, you can use this request
- 'Work Orders Queued' GET - if you know the job hasn't begun, but is instead waiting in queue, you can get information making this call
Once you've identified the Work Order ID, you can make the Work Order GET request (ex. https://api.scout.systems/v1/workorders/{id}). If successful, you should be able to see unit / station / user and workorder related data.
You can then use elements such as unitID and userIDs to cross-reference data found when making 'Units' or 'Users' GET requests in our system. You can use that information to then dig into things like Users' "applied hours" (time spent in our system), as well as Unit data such as average build times, or step related data. There is a massive world of information available to you!
2 min read
