As an example of the API, if I was writing a symbol lookup command for
Emacs, it could simply make a HTTP GET request to

     https://api.schemers.org/v1/symbol?
       ?name=make-array
       &type=procedure
       &format=sexp

And the API would respond with an S-expression like:

     (symbol make-array
       (srfi 122 (procedure ...))
       (srfi 164 (procedure ...)))

Or I could list all the symbols defined in a particular SRFI:

     https://api.schemers.org/v1/srfi/122

     (srfi 122
       (title "Nonempty Intervals and Generalized Arrays")
       (symbols
         ...
         (make-array (procedure ...))
         ...))

The precise output format would subject to debate and evolution. But the
point is that this API could be the first stop for tool writers, and the
source HTML would be directly consumed only for special purposes. It's
easy to add new API endpoints if people need new output formats and
features (e.g. JSON or XML or others).

As an example of prior art, the Wikipedia API allows one to retrieve the
desired parts articles in different formats:
https://en.wikipedia.org/wiki/Cape_York_meteorite?action=raw&section=0
It's much more convenient than trying to parse entire articles yourself.
The people who programmed the API did all the hard work :) Of course,
the API is probably based on an open source library so really dedicated
people can still download that library and do it manually. It will just
be less worthwhile for general usage and simple tasks.