Why not just run and query an Onionoo server?
Onionoo isn't really optimised in regards to giving out lists of exits, the parsing of the JSON sounds like a duplicate effort to me. Also, shipping Onionoo with every facilitator seems a bit overkill.
It's not Onionoo's primary purpose to give out lists of exit addresses, but it provides that information, too. It just doesn't offer good query parameters for that use case. But I think you should do okay downloading the full set of relay summaries once per hour and cache that data locally. The URL is:
https://onionoo.torproject.org/summary?type=relay&running=true
The protocol specification is here:
https://onionoo.torproject.org/
I wouldn't recommend running your own Onionoo server, particularly not on every facilitator. But if you cache results, you don't really have to do that.
Is running a Tor client really so heavyweight? Let me explain more about what we're trying to do. The facilitator needs to know, for each request, whether the requestor is a Tor exit.
A Tor client won't tell you that, or at least not very reliably. The reason is that some relays are multi-homed, using different IP addresses for registering in the network (which is what the Tor client would tell you) and for exiting to the Internet.
If you want to learn about both network-internal and external IP addresses, you want to download TorDNSEL's exit list. The URL is:
http://exitlist.torproject.org/exit-addresses
Metrics archives these exit lists and has a format description here:
https://metrics.torproject.org/formats.html#exitlist
I read that Onionoo reads its information from metrics; where does metrics get the data from?
Metrics aggregates data from network statuses, relay descriptors, and TorDNSEL exit lists, among others.
So, in summary, I could see you using either TorDNSEL's original data or Onionoo's summaries.
If you decide to use Onionoo, we should add Flashproxy to the list of known clients on Onionoo's project page, so that we who we have to contact when we're planning changes to Onionoo's protocol.
Best, Karsten