Getting a Key For Readworks Without Losing Your Mind
Readworks keys are generated through the platform's admin dashboard and handed out to teachers who want to create class rosters quickly. I found this out the hard way after trying to manually enter thirty student emails one by one. The key system exists to bypass that particular pain. Here is how it actually works when you are sitting there at 11pm before a lesson. Log into your Readworks teacher account. Navigate to Classes in the left sidebar, then click Invite Students. You will see two options: enter student codes individually or generate a class access key. The key is a random string of characters — usually eight to twelve alphanumeric symbols — that students type in to join your class without you having to manage individual invitations. The key is valid for seven days by default. After that window closes, it expires and you have to generate a new one. This is not a flaw in the system. It is intentional. I have watched several teachers leave old keys sitting on their classroom whiteboard for months, and students from previous years keep joining classes they should not have access to anymore. Change your key every semester at minimum. A two minute task that prevents a whole lot of confusion.
One edge case worth noting: if your school uses Google Classroom integration, the key system becomes largely irrelevant because student rosters sync automatically. But the integration only works if your district has Readworks whitelisted in their Google Workspace settings. I spent an entire faculty meeting trying to debug a sync failure that turned out to be a district-level block on third-party educational apps. Worth knowing before you assume the platform is broken. There are a few things about Readworks keys that the help documentation does not really cover clearly. First, a single class can only have one active key at a time. If you generate a new key while an old one is still in use, the old key immediately becomes invalid. I learned this when a student showed up late to class and couldn't join because I had accidentally regenerated the key five minutes earlier to send to another section. The student thought I was giving them a fake code. I was, technically. Second, the key grants access to your specific class roster, not to Readworks itself. Students still need their own Readworks accounts. The key just tells the platform which class to place them in once they log in. Teachers sometimes assume the key is a password to the content library. It is not. It is an enrollment token. Mixing these up causes a lot of support tickets that could be avoided with one sentence of clarification.
The main limitation of the key system is that it offers zero granularity. You cannot restrict what a student does once they join through a key. They get the same permissions as any other student in that class. If you need different reading levels or differentiated assignments for different students within the same class, the key system does not help with that. You would need to use Readworks' grouping features inside the class dashboard instead. The key is purely for enrollment, nothing more. Another practical issue: keys do not carry over between academic years even if you keep the same class name. Readworks resets class data annually unless you manually export and import your rosters. I have lost entire year-long reading level progressions because I assumed the platform preserved them automatically. It does not. Export your data before June, even if you think you will remember to do it later. You will not. If you are running a large department and need to distribute keys across multiple teachers, Readworks does not have a bulk key generation feature. Each teacher generates keys independently within their own account. There is no central admin panel for key distribution at the district level within the standard free tier. The enterprise version adds some of this functionality, but most public schools and Title I institutions are on the free plan. Work within those constraints.
Get the Full Details

One workaround I use for the expiration problem: I keep a private document with the current active key for each of my classes and update it immediately whenever I regenerate. Not elegant, but it means I am not digging through old emails or chat messages when a student complains they cannot join. Simple tracking prevents simple headaches.