Wordle API research

a24vinla commented

2026-04-16 09:14:12 +00:00

Collaborator

It would be fun to feature wordle (or other games like it) in a card. It would be nice if an API exists for this, please research!

Parent Issue: #342

It would be fun to feature wordle (or other games like it) in a card. It would be nice if an API exists for this, please research! Parent Issue: #342

a24vinla added the

enhancement

feature request

labels

2026-04-16 09:14:12 +00:00

c24carso was assigned by c24elipe

2026-04-16 09:26:46 +00:00

c24carso commented

2026-04-16 11:12:11 +00:00

Collaborator

Wordle API research

https://wordlehints.co.uk/wp-json/wordlehint/v1/answers
A hosted rest API that requires no authorization and uses HTTPS get requests. The API maintains a consistently formatted historical dataset of all official Wordle answers with daily updates, including puzzle dates, puzzle numbers, solutions, and difficulty ratings. There is a /latest endpoint for the most recent answer. Limitation: this API is one day behind NYT official Wordle.
https://github.com/petergeorgas/Wordle-API
It is a REST API built with Next.js and TypeScript designed to run as a serverless function, intended as a backend for Wordle clones. The point of this API is to allow a Wordle clone that keeps the answer off the user's computer. It does not currently check whether a guess is an English word that exists. A live version is hosted at https://wordle-api.vercel.app/, it serves its own answer from its own word list, not the official NYT answer of the day.
https://rapidapi.com/azizbergach/api/wordle-game-api1
It is available through the RapidAPI marketplace, requires an account and API key, and has free and paid tiers depending on request volume. Like option 2, it serves its own word list and is not tied to the official NYT answer.

Summary: None of the available APIs provide the current NYT answer of the day, they're either one day behind or use their own list of words. If we want a playable Wordle card, we could use one of the clones or if we just want to display the official Wordle answer we can do yesterdays with the first option provided.

### Wordle API research 1. https://wordlehints.co.uk/wp-json/wordlehint/v1/answers A hosted rest API that requires no authorization and uses HTTPS get requests. The API maintains a consistently formatted historical dataset of all official Wordle answers with daily updates, including puzzle dates, puzzle numbers, solutions, and difficulty ratings. There is a /latest endpoint for the most recent answer. Limitation: this API is one day behind NYT official Wordle. 2. https://github.com/petergeorgas/Wordle-API It is a REST API built with Next.js and TypeScript designed to run as a serverless function, intended as a backend for Wordle clones. The point of this API is to allow a Wordle clone that keeps the answer off the user's computer. It does not currently check whether a guess is an English word that exists. A live version is hosted at https://wordle-api.vercel.app/, it serves its own answer from its own word list, not the official NYT answer of the day. 3. https://rapidapi.com/azizbergach/api/wordle-game-api1 It is available through the RapidAPI marketplace, requires an account and API key, and has free and paid tiers depending on request volume. Like option 2, it serves its own word list and is not tied to the official NYT answer. **Summary:** None of the available APIs provide the current NYT answer of the day, they're either one day behind or use their own list of words. If we want a playable Wordle card, we could use one of the clones or if we just want to display the official Wordle answer we can do yesterdays with the first option provided.

c24carso added the

needs review

label

2026-04-16 11:13:26 +00:00

b24krila was assigned by b24johka

2026-04-20 10:01:05 +00:00

b24krila commented

2026-04-20 11:04:31 +00:00

Collaborator

The research provides a useful overview of the available Wordle APIs which is good, it also points out that none of the APIs provide the current NYT answer of the day.

However the analysis is mostly descriptive rather than evaluative. Which provides a good overview but that doesn't help making a decision for the actual implementation.

As it lists the different APIs and then briefly explains what each one does but it does not compare them, or provide a clear recommendation for use. which makes it hard to determine which option is the most suitable.

Overall the research is good for a starting point, but a clear decision regarding which API to use is still needed.

The research provides a useful overview of the available Wordle APIs which is good, it also points out that none of the APIs provide the current NYT answer of the day. However the analysis is mostly descriptive rather than evaluative. Which provides a good overview but that doesn't help making a decision for the actual implementation. As it lists the different APIs and then briefly explains what each one does but it does not compare them, or provide a clear recommendation for use. which makes it hard to determine which option is the most suitable. Overall the research is good for a starting point, but a clear decision regarding which API to use is still needed.

b24krila removed the

needs review

label

2026-04-20 11:05:08 +00:00

a24timsv was assigned by a24julot

2026-05-05 07:07:17 +00:00

a24timsv commented

2026-05-11 09:05:32 +00:00

Collaborator

Been looking through option 1 and 2 and they both have the same flaw, they don't check the word. While option 1 doesn't state it directly it doesn't have an endpoint that checks if the word is a real word, or even if the word is the correct one. It can only give the answer for that day for Wordle. It is not meant to be a API for implementing your own Wordle clone, it is a documentation (best explanation I could come up with) of Wordle or a helper/cheat sheet for it. In order for this to work for us we need to implement our own dictionary, and match with Wordle (I don't even know how we would do that).

The same problem exist within option 2, as it states, it doesn't check the word. Thus the same issues exist within this option.

Option 3 actually does everything you would expect a Wordle clone to do, but as mentioned above, it does require an account. Also it is limited to 60 request per day for the free plan and I find it hard to believe that the University would pay for this.

Option 3 is obviously best, but we are unlikely to actually use it since it costs money.
Option 2 works, but won't check if the word is a real word.
Option 1 just gives the word, so we have to do all logic on our own.

Been looking through option 1 and 2 and they both have the same flaw, they don't check the word. While option 1 doesn't state it directly it doesn't have an endpoint that checks if the word is a real word, or even if the word is the correct one. It can only give the answer for that day for Wordle. It is not meant to be a API for implementing your own Wordle clone, it is a documentation (best explanation I could come up with) of Wordle or a helper/cheat sheet for it. In order for this to work for us we need to implement our own dictionary, and match with Wordle (I don't even know how we would do that). The same problem exist within option 2, as it states, it doesn't check the word. Thus the same issues exist within this option. Option 3 actually does everything you would expect a Wordle clone to do, but as mentioned above, it does require an account. Also it is limited to 60 request per day for the free plan and I find it hard to believe that the University would pay for this. Option 3 is obviously best, but we are unlikely to actually use it since it costs money. Option 2 works, but won't check if the word is a real word. Option 1 just gives the word, so we have to do all logic on our own.

a24timsv commented

2026-05-18 06:08:52 +00:00

Collaborator

I just realized (and writing this as a confirmation) that using option 2 fulfills all the requirements we have just by keeping our own word list. The GitHub project features a word list that itself uses to randomize the daily word. We can keep the same word list locally and use it as a check if the word sent is a real word. With roughly 1300 words and the project not being updated for 4 years, the word list are unlikely to change.

The flow for this card would be roughly:
The user enters a word -> The word is checked if it is in the word list (locally) -> If it isn't, return error message. If it is, send a POST with the word to the API -> Display the information received from the API.

The flow loops until the user wins or loses. If the API ever decides to check the word on its own we can just drop our check locally and the View should work the same.

I believe this is doable and can be worked on by two people simultaneously, one creating the service/API call handling and one doing the frontend.

I just realized (and writing this as a confirmation) that using option 2 fulfills all the requirements we have just by keeping our own word list. The GitHub project features a [word list](https://github.com/petergeorgas/Wordle-API/blob/main/word-util/word_list.ts) that itself uses to randomize the daily word. We can keep the same word list locally and use it as a check if the word sent is a real word. With roughly 1300 words and the project not being updated for 4 years, the word list are unlikely to change. The flow for this card would be roughly: The user enters a word -> The word is checked if it is in the word list (locally) -> If it isn't, return error message. If it is, send a POST with the word to the API -> Display the information received from the API. The flow loops until the user wins or loses. If the API ever decides to check the word on its own we can just drop our check locally and the View should work the same. I believe this is doable and can be worked on by two people simultaneously, one creating the service/API call handling and one doing the frontend.

a24timsv added the

reviewed

label

2026-05-18 06:09:41 +00:00

a24timsv referenced this issue

2026-05-20 14:24:31 +00:00

Implemenation of Wordle API #1059