Page MenuHomePhabricator

API Campaign Events: Add a parameter to increase the 20 participant limit
Open, Needs TriagePublic

Description

Description

When querying the Wikimedia Campaign Events API to retrieve public participants for an event, the response seems to be limited to a maximum of 20 participants, even when there are more than 20 registered.

In MediaWiki Core APIs, parameters like cmlimit and maxlimit allow developers to specify higher limits when retrieving data (e.g., category members). Implementing a similar approach in the Campaign Events API would improve efficiency.

Details

Example API response (generic participant data)

 (LIMIT 20 PARTICIPANTS)
{
"participant_id": XXXXXX,
"user_id": XXXXXX,
"user_registered_at": "YYYYMMDDHHMMSS",
"user_registered_at_formatted": "HH:MM, DD Month YYYY",
"private": false,
"user_name": "ExampleUser",
"user_page": {
  "path": "/w/index.php?title=User:ExampleUser",
  "title": "User:ExampleUser",
  "classes": "mw-userlink"
}

Request for Improvement

Could an optional limit parameter be added to retrieve more than 20 participants per request?
In MediaWiki Core, APIs like categorymembers support cmlimit and maxlimit for flexible pagination. Could a similar parameter be implemented here?
If the 20-participant limit is intentional, could the reasoning be documented?
Are there performance concerns preventing an increased page size?

Proposed Solution

If feasible, allowing a limit parameter (e.g., limit=50) with a defined maxlimit would improve efficiency when handling large participant lists. Otherwise, clarifying the restriction in the API documentation would help developers optimize their queries accordingly.

Thank you for considering this request.

Event Timeline

P.S: I have read that last_participant_id exists for pagination, but it is not the most effective for research projects or that the limit should be higher like maxlimit

Danielyepezgarces renamed this task from API Campaign Events limits public participants to 20 (Pagination issue?) to API Campaign Events: Add a parameter to increase the 20 participant limit.Mar 10 2025, 2:31 AM
Danielyepezgarces updated the task description. (Show Details)

Additionally, I believe that when include_private=false is used, a counter with the number of private users should be returned.

When querying the Wikimedia Campaign Events API to retrieve public participants for an event, the response seems to be limited to a maximum of 20 participants, even when there are more than 20 registered.

Yes, indeed. This is the documented behaviour.

Could an optional limit parameter be added to retrieve more than 20 participants per request?
In MediaWiki Core, APIs like categorymembers support cmlimit and maxlimit for flexible pagination. Could a similar parameter be implemented here?

Note that the parameters you're referring to exist in the Action API, but this endpoint (really, all the CampaignEvents endpoints) use the newer REST API. I would like to implement pagination for this endpoint, and also other endpoints. The main problem is that, as far as I'm aware, the REST framework does not advice on the format to use for pagination parameters, e.g., whether endpoints should use uniform names; and it does not provide convenience code either (for example, to avoid repeating the same 3 parameter definitions everywhere). This is also why we don't currently have an endpoint that lists all events (T387233). T234470 was created to investigate this in 2019. Sadly, nothing has happened since then.

Other than that (and the absence, so far, of a concrete use case), there are no concerns.

My project uses recently this API: https://es.wikipeoplestats.org/event/tiempo_feminista_para_editar_wikipedia

And in the future I think that the current pagination would leave a lot to be desired, since by limiting the results to 20, if an event has more than 200 participants, doing a pagination of 10 cycles would take longer to calculate the response.

Well, listing all the events seems good to me

And in the future I think that the current pagination would leave a lot to be desired, since by limiting the results to 20, if an event has more than 200 participants, doing a pagination of 10 cycles would take longer to calculate the response.

You don't need to convince me :) As I said, that's something I've been wanting to do since we first created the endpoint, but didn't because we didn't have neither standards nor use cases. Over the years we've seen a few potential use cases, but still no standards. I just posted a comment in T234470, let's see.

Can we have the limit by default 50? Is there any reason why it has been hard-limited to 20 results? @Daimona

Can we have the limit by default 50? Is there any reason why it has been hard-limited to 20 results? @Daimona

I think there were some performance concerns when requesting too many users at once, see T345250. Those have been partly fixed back then, as the same API request I used for that task is at ~150ms now (of which ~60ms inside the actual run() method, see profile) when made by a non-organizer user. So I think it might be fine to increase the limit to 50, but I'd still want to do some profiling anyway (given the low limit, we never really spent time optimizing the endpoint after that task in 2023). Of course, I would still prefer if we had pagination, but I'm not sure when T234470 will be worked on.