Nexus Keycode exceptions

DQ token is “Short Test token” - 2 min (143 253 222 433 244) small keycode.


The way the code should work is to only allow 2-minute short test credit to be added if the device currently doesn’t have any credit. Check out the source code here. If in step 5 of your test the device gives credit, then there is a problem somewhere.

It behaves this way because this keycode was designed to disambiguate whether a unit cannot turn on due to no credit or another technical problem. So if a device is not turning on, a technician could use this keycode to add a little bit of credit. If it turns on, then it means the customer just needs to buy a real keycode for more credit. If they already have credit, then we want to discourage the ability to get more credit for free.

This is especially true because the 2-minute short test keycode is universal across all devices and can be entered an unlimited number of times. So only allowing the credit to be added once the credit is fully expired will create an additional barrier to entering the keycode and getting time that is not paid for.

The 1-hour DQ keycode, also called an OQC keycode, is universal across all devices but this risk is managed because they can only be entered a limited number of times during the device lifetime.


Hi Eric,

Since we still testing our product as per the Test plan recommended by your team, I will share the results once done. Meanwhile can you please tell, how & what device information (database) will be required to share with Angaza team to enable our devices in the field.
How we can share secret key, serial id etc?? is there any specific process or format which we need to follow?


We will provide you credentials to use our Nexus API. You will be able to use the methods that are for Manufacturers. With this API, you can make request us to make a record for each unit including the ID (that will be written to the device as well as displayed on the outside for the customer to us) and the secret key. Then you will be responsible for writing that information to the device.

We hope to publish some guides for this very soon that you can use.


Hey Eric,

I have some queries on Keycode Grace periods.

  1. If I enter 6 wrong keycodes in product & it goes into keycode entry lock mode for 12 min, after 12 min if I enter valid keycode, will this grace period be reset?
    Can I enter more 6 invalid keycodes?

  2. In my product I am facing an issue,
    a. Enter 1st Keycode – accepted by product
    b. Enter 2nd Keycode – accepted by product
    c. Enter 3rd Keycode – accepted by product
    d. Enter 4th Keycode – accepted by product
    e. Enter 5th Keycode – accepted by product
    f. Keycode entry blocked – Product is locked for 12 min

Can you please guide where should I focus to target this issue??

Can you elaborate more on this Nexus API? Can we generate Serial Id & Secret by our own? How to share secret key with Angaza?


Sorry for not responding to you earlier about your questions on Keycode grace periods. Did you get that figured out? The short answers are that:

  1. No, this will only add 1 more keycode to the rate-limiting bucket and the grace period keycode count; there are a maximum of 6 keycodes in the grace period count. The function of the grace period count is to auto-refill the rate-limiting bucket after a reset event, conserving any keycode entries that might have built up. So if you reset the device at this point, you would still have 1 keycode in the rate limiting bucket. You would need to wait 12 min * 5 more to completely fill the grace period count with 6 keycodes. Then if you reset the device, you’d still have 6 keycodes. But if you waited 12 minutes more, then you’d have 7 keycodes in the rate-limiting bucket but still 6 in the grace period count; if you reset now, then you’d have 6 keycodes in the rate-limiting bucket, due to the grace period bucket refilling it automatically from its maximum value. If you entered 1 more keycode and then reset it, you’d have 5 keycodes in the rate-limiting bucket, until 12 minutes passed again to refill the grace period count.

  2. I would expect (f) to be accepted – the grace period count should start from 6. Are you sure the device NVRAM was freshly erased and reprogrammed or 12 min * 6 passed to completely refill the rate-limiting bucket and grace period count?

As for Nexus API, no, we will provide the Nexus ID and secret. We call this “creating unit records”. You just need to request this information from us. Here is a link to the documentation. Would you like to try it? If so, please send a request to create Nexus API credentails to