API

COMMENCER

OverviewThe TimeWellScheduled API allows you to call modules with the TimeWellScheduled service that respond in standard XML. Individual modules and their properties are detailed blow.

The API URL is located at https://api.timewellscheduled.com/response.asp

The TimeWellScheduled API isn’t your typical API in the way that it doesn’t rely on different HTTP request methods (GET/PUT/INSERT/DELETE). Instead, we’ve decided to KISS and use only GET HTTP Requests over HTTPS (at this time), and to simply pass the desired method along with the variables for the request itself in a standard, well-formatted URI.

This has a number of advantages and will make your live easier when working with our API as:

There is no need to switch between different HTTP request modes in your application

You can convert your data straight to URI-formatted text in whatever language you are using

Our ‘Method’ names are a bit more intuitive

Register

We are handling all registrations internally. To get started please provide us with:

Application Description – How you plan on using our API.

Compliance w/ Terms – Acknowledgement that you have read and agree to our API.

While you wait for your registration to be complete, you may want to also look into the bCrypt irreversible encryption algorithm. TimeWellScheduled utilizes bCrypt to store all passwords, and provide you with employee passwords in this encrypted format. Your application will need to verify passwords with these bCrypt hashes, meaning you will need to bCrypt-hash these on the client-end. To get comparable results, you will need the bCrypt Salt which is unique to each company; we will pass you this information when your application authenticates for the first time.

The staff at TimeWellScheduled strongly believe in the power of bCrypt, and our clients trust in our choice of using this algorithm to prevent reverse-engineering of hashes, and prevent man-in-the-middle attacks of clear-text passwords being transmitted across the network. If bCrypt implementation proves to be difficult, we’re more than happy to help!

Action 0:
Virtually all modules in our API require verification for access. This is the first module your application will call, upon launch. The Verification process purpose is to exchange an API Key for confirmation that your application will be accepted by our servers. Additionally, upon successful exchange, we will provide company information, and a company logo that the company has provided ahead of time, as well as a list of employees authorized to use your application and their data. Also, a bCrypt Salt Hash will be provided, which you can use for password verification processing.

Full details regarding modules can be found in Modules section; for now, bear with us as we discuss the procedure for authentication.

All request are made via HTTPS GET requests, and requires a series of variable and value pairs appended to the API URL. Here is the format of that URL, and we’ll discuss each option below:

Request:

Response:

Upon successful validation, you will receive in the Message portion of the XML a series of values: a list of employees enclosed within <employees>
tag, as well as a <branding> tag contains the name of hte company, and a logo url as an attribute. Finally, the bcrypt Salt to use for local verification of passwords is provided for this company; this is not to be cached, as it may change at any time; store this temporarily in your client application to use for verification of typed passwords.

The TimeWellScheduled API allows you to call modules with the TimeWellSchedule service that respond in standard XML.

The API URL is located at https://api.timewellscheduled.com/response.asp

All requests to the TimeWellScheduled API must be packaged as encoded URI Strings, and appended to the API URL in a well-formed GET HTTP Request Method. Virtually all requests require an API Key and Application ID. There are additional requirements for most API calls, as follows:

Remember that any data passed to the API must be in a URI string, and properly encoded (eg, %20 in place of spaces). Here is an example of how this can look in PHP:

Responses

Upon your application sending a properly-formed request, with an appropriate value for action, the server will return an XML response:

Success is equal to 1, meaning our request was successful. We’ve been given an EventID, and in the message, we’ve been given a XML list of employees to store temporarily, some branding information, and the bCrypt Salt used to hash typed passwords and to compare against.

Step 2:

The first employee punches in for his or her shift to start:

The server responds with XML code, indicating that this employee is on-­‐time, and has a message waiting for them; it also retrieves the photo1.jpg file mentioned in the ‘a’ attribute (uploaded on a separate thread, and placed in a holding area), and attaches it to this event.

The employee would then dismiss this message.

Step 3:

The second employee punches in for his or her shift to start:

The server responds:

The employee confirms the message, and the UI is reset.

Step 4:

The first employee needs to punch in to begin their meal:

The server responds:

The employee confirms the message, and the UI is reset.

Step 5:

The second employee has already successfully punched out for a regular break, and returns, attempting to punch in immediately for lunch:

However, this employee tapped ‘Meal,’ but was already out on break; the server responds: