Kayako API and direct database access
Updated April 08, 2015

Kayako API and direct database access

CJ Estel | TrustRadius Reviewer
Score 7 out of 10
Vetted Review
Verified User

Software Version

Other

Overall Satisfaction with Kayako

Kayako was used at a past organization for support tickets via email. We restricted use to email in most cases and did not expose the Kayako interface to our customers. We wanted a simple email address they could send support requests to that would allow us to track and distribute work to employees. Kayako provided this. We purchased and hosted Kayako in-house so there were not any 3rd party dependencies..

Kayako has an API that allowed us to build tools to interface and expand Kayako's functionality. We used the API to build a website that would show how many tickets were in queue and would alert the help desk to new tickets from a large display with an audible noise that had the website up 24x7. This allowed for us to have very quick response times to new tickets that came in as they had to be acknowledged to make the loud beeping alert stop.

Since Kayako runs on an open source database (mysql) and we had control of the infrastructure that it was hosted on, it allowed us to directly interface the database to further expand functionality. We built a billing module outside of what Kayako offers for billing that allowed us to pull the specific data we needed to bill our customers. This gave us the capability to apply different rules to customers and how they were billed based on defined rules we setup. The custom interface also put data in a format that was easier to work with for our billing department.

From a technical standpoint Kayako is versatile, but there are some oddities to the way they track certain things that may require internal business rules. For instance, they have the time worked and time billed as separate fields on a ticket. This can be very nice if used correctly, but seemed redundant to employees and sometimes they would not input data correctly. This was another reason we elected to write our own billing module so that we could have more insight into what data was pulled and highlight areas that may have been worked but not billed so that the differences could be investigated.

Kayako stores almost everything in the database. This is very nice for modifying things and not needing permissions on a bunch of directories for configurations and file uploads. For our organization (less than 10 users) this worked great and we never had any problems. I did worry about what response times would be from the database and if it would slow down in the event we were to have a large number of concurrent users. Every page load had numerous queries to the database. I would think it could benefit from memcached to assist in scaling to larger environments.

File attachment storage location was a configurable option as to whether they were stored in the database or on the file system, so that gave the option of keeping the database footprint much smaller.

Backups of Kayako were very straight forward. We backed up the directory for the webserver with rsync every hour, and the database was backed up daily with mysqldump and we also stored incremental backups every 15 minutes from mysql's binary logs.

Overall we were happy with how Kayako performed. It is not the cheapest system we evaluated, but it did work better than many of the open source solutions we evaluated.
  • Kayako handles email integration through pop very well
  • Kayako is very configurable
  • Kayako's API was well documented and easy to implement custom scripts against.
  • Kayako has a large number of queries to the database for each page load. This is fine for small installations, but I would think it could become a burden in large instances (this is for self hosted version only)
  • Kayako allows for so much information that it can take awhile to get it configured to just ask for what you need and not overwhelm you with options
  • Not necessarily a Kayako issue, but we ran into a problem where a ticket was "stuck in the queue" It turned out that there was an attachment larger than what the php was configured to support, so the ticket would be created, but because the attachment would fail to upload correctly, it would not remove the item from the pop mailbox and it would download it again and again and again until we figured out the issue. If they were to wrap the ticket creation into a transaction and not create the ticket prior to fully processing the message they could then check the error response code on file upload and maybe create a single message that indicated the real problem.
  • Tickets were definitely responded to faster once we implemented the audible alarm that would go off when new tickets came into the queue. This was possible because of the API.
  • Since the system was email based we could set our monitoring software up to generate tickets automatically via email for customers when it found something out of the ordinary.
We evaluated Spiceworks and it tried to do too much. Kayako addressed our need for email support and distributing/tracking work without trying to introduce direct monitoring, knowledge base, and all kinds of other tools. It was much simpler to configure for our needs.
Access to the API and to the raw database were the major pro's from my standpoint. Though it is more work to manage your own instance of Kayako, that was preferred for our installation. I wouldn't think you would get the direct database access to script against through their hosted version.

Using Kayako

I am no longer with the company that was using this, and they were recently bought out by a larger organization that uses an internally developed software suite. It is unlikely for that reason that they will renew or keep any service with Kayako.

Kayako Implementation