We were interested in creating a hack with some of the other API's, but we were interested in trying out Credible's challenge as well as learning a new platform for web development, Django.

What it does

The web application is meant for employees to be able to log into the service and easily view their daily schedule of meeting with various clients by plotting their addresses on a map with the shortest route to each client, while taking into account the employee's current location. Next to the map, there is a list of clients with basic contact information available in a dynamic dropdown section.

How we built it

We spent a good amount of time discussing what to build and what tools to use with it. We had discussed other API's like IBM's BlueMix, or Capital One's Nessie, but with their overwhelming popularity, these API's seem to get submissions that have been repeated over and over again. Since we have never worked with Credible's API, we decided to give it a shot.

Our development platform was definitely going to be a website, since we are mostly familiar with how to implement a website compared to a mobile application. We chose the standard HTML/CSS/JS trinity for the front-end, and were given a tip to try using Django due to its ease of setup and feasibility. We received a few tips from a friend on how to get started with Django, so we were up and running fairly quickly.

Looking at the Credible API, we were able to send HTTP requests for data on clients, employees, and their scheduling. We tested out the API with a few simple python scripts to establish success with interfacing with the API. The next day, we spent time migrating databases in SQLite to match with the fields we needed from the API, as well as setting up the model structure of our web app in Django. We also spent time research different (free) website templates, and mixing and matching the pieces we liked until we crafted our final design layout. We populated our databases with the dummy data Credible had provided to us, and created a bit of our own data to make our application more presentable.

Challenges and Difficulties

Unfortunately, we were actually unable to successfully interface Django with our front-end, and weren't able to make the application behave as intended. Since each component was designed independently, we had some issues with getting both things to meld smoothly with each other. We tested the animation events on our front-end and they behaved as normal, and were able to properly populate, retrieve, and send information from our database to some basic website, but there were too many complications to properly make things work:

-We were unfamiliar with the templating system of Django, and were a bit taken aback at how we were able to preprocess html with python. -As a team, we haven't had much experience with API's (though python's request module made things easy at first) -There were a few errors with how Django sent data through its views, with data being difficult to be JSON-ized -Most each of us haven't been to more than 3 hackathons, or have been exposed to languages other than C, Java, and HTML -The API didn't exactly have the best documentation (but we did the best that we could!) -The API had mostly empty data entries, with much of the employee's information being null except their names and ID's -Since we were given an md5 hashed password shared across all employees/clients instead of a plaintext password(s), it made it somewhat difficult to implement a proper/legitimate login page -The API was vast and provided a lot of information (much of which was undocumented) which made it difficult to discern what information would help us best to develop our app

Because we were unable to make a working finished product, we decided it would be best to show how an actual working product would have functioned and looked like, and so we took the data from the API and directly inserted it into our page as a filler where Django preprocessing commands would have been.


For most of us, this was likely one of the most intensive projects that any of us had participated in. We felt that although Django was new and the API was difficult to use, we were still able to make something that was at least presentable to an audience. We also felt accomplished in getting our feet wet in what web development can produce, as well as how powerful python is as a language.

What we learned

-Research is important for any hackathon (we spent 4 hours on research and ran smoothly until the last 10 hours) -Its very helpful to know the tools/frameworks ahead of time, but not necessary -Communication and a good attitude always makes these events a nicer place to be!

What's next for Flow

We might consider finishing up the interfacing at a later point as an exercise for learning Django (although we'll be very busy soon with midterms and finals).

Share this project: