Our REST API can be used with any app. Once you have your apiKey and apiSecret you can call the API for the following services: match, save, verify, deleteuser, checkuser.

Where to start?
First, sign up and download SDK here. You will find your apiKey and apiSecret after signing in your TypingDNA account.
For support and more information contact us at developers@typingdna.com
First you need to import the typingdna.js file in the page that wants to record a typing pattern. You will need to record typing patterns when a user first creates his account and again whenever you want to authenticate that user on your platform. You can host the .js file yourself.

// Import the .js class in page (head section)
<script src="/scripts/typingdna.js"></script>

To initialize the class just use the following JavaScript lines (in a <script> section):

// Initialize the TypingDNA class (creates an instance)
td = new TypingDNA();
// Start recording (you can enable recording from the start)
td.start();

To retrieve a typing pattern you have to call the .get() function whenever you want to use/save the current recorded pattern. Recording is done within the entire web page, the user can type in multiple text fields or even outside of text fields.

For example you have a form and at the end you have a “Submit” button that will first get the recorded typing pattern and then it will send it to your server along with other data recorded within the form. From there you will be able to connect securely with TypingDNA Authentication API.

Example:

// Get a recorded typing pattern for the entire session after a page has loaded and the start() function kicked in
currentTypingPattern = td.get();
// Get a recorded typing pattern for the last max. 300 chars typed
currentTypingPattern = td.get(300);
To have the best accuracy one should be aware of how text statistics are used in typing biometrics. Below is a list of rules that you should follow.

Q: What makes a typing pattern more accurate?

1. Many different and rare characters. When you have a complex text (15-25 different chars), with a good percentage of usage per character, your user profile accuracy increases, also try to use often chars that are usually found on the lower row (z,x,c,v,b,n,m) or any rare ones as these seem to hide higher differences in typing.

2. Longer texts. The longer texts allow for the recording of more accurate statistics about the pressed keys, therefore allow for the recording of a better user profile. For enrollment, we recommend recording 170+ chars of text, while for matching afterward you can have even as low as 90 chars (120 is recommended).
3. Natural texts. Those complex texts that are easy and fast to type are better samples for the true profile of a user’s typing. The easier a phrase is to type, the more natural the typing, therefore better accuracy.
4. Focus on lower case, letters only. The more natural typing happens on lower case letters (compared to numbers and symbols).

Q: What can decrease accuracy? (and increase false positives & false negatives)

1. Enroll and verify texts are similar. If the texts recorded for enrollment and those recorded for verification are similar (a lot of similar/identical words), they also force the users to type somehow similar to others due to a natural tendency to type more similar when letters come in similar order.

a. Note that there is only a slightly higher chance of getting false positives when you have a higher symmetry between enroll and verify texts, you should worry about it especially if you’re using very short texts (70-90 chars).

Too many identical chars. Texts containing an average of less than 15 different chars, even if the whole text is longer than usual. Since we capture fewer different chars you’ll get less accuracy in matching that will translate in both false positives and false negatives.

Q: Can we use random texts? (like in one of your website demos)

The only reason we use random texts in our online demo is to gather as much data as possible on random texts in order to improve our algorithms. You can use random texts too, but you don’t have to.

All we ask is make sure your enrollment and verification texts are different from each other, and if you use the match function make sure that the provided typing patterns are recorded on different texts.

Q: So what do you recommend to use as texts?

1. Example for an LMS (learning management system). Some good examples would be texts that get the user permission/agreement to be recorded, or the fact that he had read and understood the terms, or even answers to particular exam questions.

2. Example for bank transactions. You can ask the user to type his hometown, name, transaction details, or other letter-based details, even ask the user to type the amount in letters, or anything creative that can also help you check that the desired action (eg. bank transfer) was indeed intended by the actual owner of the account.

3. Other. Sometimes the user has some details that you can verify (eg. email, name, password), that are also required to perform the desired step, you can always ask some more details and record the user typing in the background, until you are sure about the user’s identity. For example an app that posts a text in the name of a user can simply use that particular text to perform the verification, or even enrollment.

5. Do not rely on numbers. Our current algorithm is not as good on numbers as it is on letters. You can record typing patterns on texts including numbers, but don’t overdo it, as our ANY text solution requires some level of incidence of the same chars in both enroll and verify steps. Unless you have some of the same numbers in at least a partial different order in both enroll and verify texts for a user, you should not rely on numbers when using the TypingDNA Authentication API.

a. Note that we’re working on algorithms that will help you authenticate users on numbers such as credit card numbers (identical enroll and verify), but these algorithms come in a different API. If you are interested please contact us.

Q: How to use the quality param?

First of all, please notice that our algorithms work differently based on what quality you request. Each quality level represents a different matching workflow that is optimized for a different purpose, therefore using the undocumented “score” param to set your own threshold is not recommended (for example: the score you get when using quality = 2 may be different than the one you get when using quality = 3).

Here is a description of each quality level:

quality = 1 means that you want most people to pass from the first try even if they type a bit different or shorter phrases, this would be useful where you have multiple other factors or when you don’t want to hurt user experience in any way. This quality level has the smallest FRR (False Reject Rate) also called False Negative, close to 2% on our testing data. Also this quality level delivers faster responses.

quality = 2 (default) means that you want a balanced error, minimizing the average of FAR and FRR. This works well for most cases, however if you want higher security you typically want a lower FAR, and you should choose a higher level of quality. This level sometimes employ cascade algorithms that may add delays of up to 5 seconds in your response. This is to prevent the failure of a potential True Positive.

quality = 3 means that you want a very small FAR (as low as 1%), therefore the entire process is more complex and tries to make sure it gets the best result at the expense of a larger FRR. For this level to work well (with minimal number of false rejects) you should consider using longer enrollment and verification texts. This level sometimes employ a more abrupt cascade algorithm compared to quality = 2, and typically has a quicker response.