If we add a prop=linterrors I think that should work out the best. Then you can retrieve the current revision text plus hte errors with prop=revisions|linterrors or something.

@Legoktm : what I meant by the "current version of the text" is not necessarily the one saved in the wiki, but the rather the current version in the external tool or in the edit box, so that a user that is modifying an article can check what errors are still there before saving the new version of the text.

What would be nice is an API call that takes a page name (or page id), an optional page contents and sends back a list of errors detected by Linter for the provided page contents (if not provided, then linter will use the last version of the article as a base for analysis).
If you can't give Linter the text to analyse, it will limit a lot the usefulness of tools to fix errors detected by Linter

This won't be a "query" api, but an "action" api (like action=parse).

T163072: Option to Do Linter/Parsoid syntax check during "Check Preview" from edit-form. (for admins and template editors etc.) has also been requested -- related, probably not the same, in case lint errors are presented in the returned HTML from the preview of the old wikitext editor

Ah, understood. OK, I'll rephrase the title.

@Ciencia_Al_Poder :

When attempting a fix for an indentified Linter issue it would be nice to know you haven't introduced a new one, or that you were not going to introduce one by adding new content. It would be nice not to introduce 'badly' structured content before it even gets saved to the wiki. Fixing up existing pages is a major task as it is, without it being a moving target.

And apologies for only just finding this.