@pushcx , I was going to open another featurereq about an API. Make requests for data, etc. Will require a lot of overhead but would allow exporting data (through an API).

Rate limiting would need to be necessary to prevent DDOS and not overflow a queue.

It's going to be an HTTPS URL that requires an auth token in a cookie and gives the user a json or zip. What would you want to see different?

an HTTPS URL

👍

requires an auth token

Ideally something that doesn't expire (closer to an API key), so I can store it in my env and my script will "just work".

in a cookie

That's fine enough. For programmatic use I'd usually prefer a header, but as long as it's easy to send using existing tools, it's not a big deal.

gives the user a json or zip

JSON is strongly preferred, in my case. Paging is also fine if you'd prefer multiple, serial requests rather than a single big one

Thanks again for putting the work in for this!

It's going to be an HTTPS URL that requires an auth token in a cookie and gives the user a json or zip. What would you want to see different?

Honestly yeah, I was under the assumption it would send an email of a user's exported data. This would work just fine.

@pushcx Is this already being actively developed?

Not that I'm aware of.

What would be the benefit of this over extending the existing routes with .json counterparts? To me the latter is both more intuitive to use as a developer (just add .json to the open webpage) and much more granular in how many rows it fetches from the DB than requesting a full data dump. If it had way more aggressive rate-limiting than the regular web UI, I wouldn't care.

The benefit is that it would support the users who've requested the ability to export all of their submissions, comments, votes, etc., rather than require them to write custom code to handle pagination and rate limiting. It also wouldn't create a broad API surface that others would assume we'd maintain.