data/devices.json records, for each vendor, whether their hardware can do OAuth 2.0 once Microsoft 365 stops accepting Basic authentication for SMTP AUTH in December 2026. It has 15 entries. Epson is not one of them, and Epson business printers and scanners (WorkForce, EcoTank) are in a very large number of offices.
That gap is the whole task.
What to send
One entry, in the shape the file already uses:
{
"vendor": "Epson",
"product": "business printers and scanners (WorkForce, EcoTank)",
"status": "check-advisory",
"models": ["the models the statement actually names"],
"evidence": "https://link-to-the-published-epson-statement",
"notes": "What breaks, which flow is supported, and which models are not promised anything."
}
status is one of: available, partial, check-advisory, unsupported, none-planned.
The one rule that matters
Every entry must carry an evidence URL pointing at something Epson published. A support page, a firmware release note, a KB article, a PDF. Not a forum post, not "my printer does this", not a guess.
If Epson has published nothing, that is a real and useful answer — say so in the issue and we will not invent an entry. A wrong row here sends an administrator to buy hardware they did not need, or to skip a migration they did need.
models may be empty if the statement is vendor-wide rather than per-model.
Where it goes
Edit data/devices.json only. The table in docs/DEVICE-COMPATIBILITY.md is generated from it by tools/build-device-table.py and checked in CI, so the two cannot drift — do not edit the table by hand, it will be overwritten.
Run this before opening the pull request:
python tools/build-device-table.py
Why it is worth your twenty minutes
This file is the only thing here that nobody else has: a hardware-confirmed record, each row backed by a link to what the vendor actually said. It is why people cite this repository. Your row is a row somebody else does not have to research at 2am with a broken scanner.
Comment before you start so two people do not research the same vendor. Ask anything in the thread - a half-finished answer with a good link beats a perfect one that never arrives.
data/devices.jsonrecords, for each vendor, whether their hardware can do OAuth 2.0 once Microsoft 365 stops accepting Basic authentication for SMTP AUTH in December 2026. It has 15 entries. Epson is not one of them, and Epson business printers and scanners (WorkForce, EcoTank) are in a very large number of offices.That gap is the whole task.
What to send
One entry, in the shape the file already uses:
{ "vendor": "Epson", "product": "business printers and scanners (WorkForce, EcoTank)", "status": "check-advisory", "models": ["the models the statement actually names"], "evidence": "https://link-to-the-published-epson-statement", "notes": "What breaks, which flow is supported, and which models are not promised anything." }statusis one of:available,partial,check-advisory,unsupported,none-planned.The one rule that matters
Every entry must carry an
evidenceURL pointing at something Epson published. A support page, a firmware release note, a KB article, a PDF. Not a forum post, not "my printer does this", not a guess.If Epson has published nothing, that is a real and useful answer — say so in the issue and we will not invent an entry. A wrong row here sends an administrator to buy hardware they did not need, or to skip a migration they did need.
modelsmay be empty if the statement is vendor-wide rather than per-model.Where it goes
Edit
data/devices.jsononly. The table indocs/DEVICE-COMPATIBILITY.mdis generated from it bytools/build-device-table.pyand checked in CI, so the two cannot drift — do not edit the table by hand, it will be overwritten.Run this before opening the pull request:
Why it is worth your twenty minutes
This file is the only thing here that nobody else has: a hardware-confirmed record, each row backed by a link to what the vendor actually said. It is why people cite this repository. Your row is a row somebody else does not have to research at 2am with a broken scanner.
Comment before you start so two people do not research the same vendor. Ask anything in the thread - a half-finished answer with a good link beats a perfect one that never arrives.