Asking for Pro Reports v2 endpoints

I had high hopes for the REST API for Pro reports…

I’m really disappointed by what was released. I will try to stay constructive here and propose a v2 that is built from scratch… correctly. It can be done and it can be simple.

V2… here we go!

  1. Make sure that the API keys are sent in the header of the request. Not as a GET parameter. The HTTP protocol already has something for this.

  2. Get rid of the old structure with things like [] as a key to format data. Use “normal” key => value pairing. No more [sections_data] or things like that.

  3. Do not HTML escape data in the API. I’m calling the REST API to display content at the command line.

  4. Standardize date formats (dates should always be something like ISO 8601) and always display in UTC.

  5. Include more information than needed. Why not include the “old” and “current” version, the slug, etc. for this call:

  6. Allow stackable calls. Let’s say I want to produce a report for site 18. As per the current API, I have to initiate 1 call to get WordPress updates, 1 call for themes updates, 1 call for plugin updates, 1 call for… Why can’t I make 1 call where I will specify everything I want in one call. I truly doubt anyone here does only one call to generate reports. We need multiple informations and doing multiple calls is slow and not really productive.

This is new API and I just can’t see how it can be usable after playing with it for 30 minutes.

That being said, it’s great that you thought about creating an API. I’m truly sorry about the fact that I cannot see what I can do with it as it lacks basic information to just recreate what I had in my current report.

The good news is it would be fairly easy to move on to v2 and fix everything. I am available to brainstorm and make it better.

By the way, there is a comma in “mainwp-pro-reports-extension/class/class-mainwp-pro-reports.php” one line 853 after ‘get_translation_pending_tokens’ that should not be there. It crashes the code when using older version of PHP. The plugin says it’s compatible for PHP 7.0 and up… 7.2 crashes.

Feel free to use me to your advantage to create a usable version of the API. It truly think it can be a great addition to your tools.


Thanks for your detailed feedback and critique @maximejobin I’ll send it over to the Dev team to review and make changes as needed in the near future. Since I am not a developer I can not give any kind of estimated time frame.

I’ll have this checked and if its an error we’ll have it updated with the next update scheduled for early next week.

Also, as a note, if you have something in particular that you need to be prioritized we do accept pull requests.


Thank you for seeing my thread for what it is!

I totally get that you are not a developer and it’s totally fine! I would encourage you and your team to validate solutions with the community before implementation. I was super excited about the REST API (and was looking for a CLI command to do the calls as we want to push the info… instead of allowing an external call).

In this business (maintenance), there are things that can make or break our businesses:

  1. Backups not working (this is something MainWP does not do!)
  2. Getting all information correctly to take action (doing a “search” for plugins and themes is simply not doable in MainWP as it takes forever to get the information).
  3. Reporting : telling the clients what we really do (otherwise, they don’t hear from us, their website has no problems… and they cancel because they think we are useless. The thing is they don’t have problems BECAUSE we are doing what we’re doing! So showing all details is super important).

I have workarounds for #1 and #2.

#3 is our biggest problem. We have a lot of information that simply cannot be inserted easily in your report because of the [section-data] and other ways of doing things that makes it really hard to manipulate. Our goal, now, is to build a web report (no more PDF) and create something that represents what we do with MainWP… but also other tools.

So, this Report API is suuuuuuuuper important to us.

If I can add more feedback…

  1. In the API, the “action” is required and I can only specify one. Why? Why can’t it get everything? Why can’t I get multiple actions separeted by a comma (ex: “installed,updated,deleted”).

  2. In your doc, the date format is “YYYY-M-D”. What is this format? In theory, this would be the expected input for start_date parameter for today: 2023202320232023-May-Wed. If I look at the examples provided in the documentation, I see this:


Note: Month does not start with 0 (1 or 5) but days are (01).

Can the documentation be updated to reflect reality?

Thank you!

1 Like

Again thanks for feedback. Just to clear up a couple of things:

  1. The only thing that is new with this release is the Reports section of the API.

The API itself has been around since late 2020. Honestly, your posts are the first I remember hearing any complaints or criticism, so we’ll review and adjust per user’s overall needs over time.

  1. You can use YYYY-MM-DD for your date format, and it will read it fine. This will be better shown when the Postman documentation is finished

We are moving the API documentation to PostMan, which should cover most documentation issues.

Okay, the Reports API is super important to you, which is awesome. That’s what I want people to say. However, the changes you are asking for will not be done overnight, so how can we help you now? Is there some small change that will make your life easier without the API being rewritten for V2?

1 Like

I don’t think that PDF report is the way go to for the future. That being said, that’s my view and I totally understand why you use PDF.

My goal is simply to be able to extract data and build reports by myself.

So, maybe you just have to produce a documentation (or maybe answer here!) about what MainWP PHP functions can I call to get the information I need to be able to extract the data.

At this point, what I want to do is this : call a PHP script I will make. This script will call MainWP functions to be able to extract all needed information to push it to our “report system”.

In other words, how can I get ALL RAW DATA for each website so I can build the report myself?

I would like to call official functions created and maintained by MainWP. Otherwise, if I call the database directly, any change made by your team could break my logic. That is why I want to use your functions as much as possible!

Am I clear about what I ask ? Do you need more clarification?
Does what I ask makes sense to be implemented in some way?

Let’s try to remain professional.

MainWP is open source, so feel to go through MainWP · GitHub and review the information on .

Closing this thread since your thoughts have been expressed.

In your doc, the date format is “YYYY-M-D”. What is this format? In theory, this would be the expected input for start_date parameter for today: 2023202320232023-May-Wed.

Regarding the date format documentation, this was totally my fault. While working on the documentation, I had in mind that YYYY-M-D would be something that users would easily understand as notation for 2023-5-20 for example, I haven’t figured that this would cause confusion and got mixed up with standard PHP notation for formatting date stamps. As soon as we realized this, we updated the documentation to correct this.

I don’t think that PDF report is the way go to for the future. That being said, that’s my view and I totally understand why you use PDF.

We can understand your point of view, but we must pay attention to all other users that still prefer to send PDF reports. Before the Pro Reports extension was developed and the Client Reports extension was the primary reporting tool, one of the most voted feature requests for MainWP was PDF reporting, so this was the reason we leaned towards including reports in PDF documents. However, there were still some users that don’t want PDF and wanted to send reports as HTML email, so with version 4.1, we added support for all reporting tokens in the Email body and email template. With this version, there is a solution for both groups of users.

So, maybe you just have to produce a documentation (or maybe answer here!) about what MainWP PHP functions can I call to get the information I need to be able to extract the data.

As you know, MainWP reporting system keeps most of the data stored in the MainWP Child Reports plugin Database tables. Extension queries for this data from child sites directly. However, for some, data is fetched directly from the API source, for example, GA. GA extension fetches data from the Google Analytics account via GA API, and then the Pro Repots gets that data. In general, the process is complex. Since the Pro Reports primary purpose is to provide users GUI to provide their clients with reports, we never thought about making extensive documentation for developers that need custom reporting solutions built on the MainWP platform.

As soon as we realized that this is also something that would be good for users, we started with Pro Reports API. Due to the complexity of PHP code that handles all the data fetching, we believe that API is the best way to get the data.

If you still believe that making a custom solution from scratch would be the best way for you to go, I would suggest reviewing the code directly in the extension to get familiar with it and see how it works. But after talking to our dev team, they said that getting ALL RAW DATA from a child site is not a good idea. There is simply a lot of data, and a query to get all at once would probably cause issues. This is why we made the API broken into smaller “pieces”. This way, overloading data should be prevented. Some hosts also Limit the response, so calling too much data in one API request is just something that could cause problems.

For all other suggestions you have, I think it might be best to simply submit feature requests at so we don’t lose your ideas and make the updates when the time is right, as we definitely wan’t to keep working on MainWP API and make it better.