Well, here is a word from me (i.e. adriverhoef).
It should be noted that it took absolutely no time at all to reprogram my script 'wcgresults', since the parts of the API that are being used by that script (i.e. downloading the outcomes of validation, mainly) didn't change!

The parts of the website that changed for me were the scraping of HTML pages that I did with my script 'wcgstats' and that cost me indeed two weeks: first off it cost me some time to find out how to login, because that has changed (I couldn't find the URL!), then base the script on the new API (defining some new programcode for one's own devices, repairing how to update the script, integrating the new task statuses, and much, much, much more), I also changed some options and redesigned the whole thing, next I needed to check all programcode and see to it that it worked OK, before it was time to (re)publish the script and make it available for downloading. I don't want to publish half work, you know.

However, since wcgstats didn't work in the beginning after the new API was put into place I also wanted/needed a way to report/log my total contribution (runtime, points, results), so I added some code to wcgresults (available with the option -SSSS, maybe you've seen it being mentioned somewhere ) so that it mimicked the output of wcgstats (called without options).

So, in the end, the duration that I mentioned, two weeks, was actually used for three scripts that needed rewriting: not only for wcgstats and for wcgresults - mentioned above - it also applied to wcgformat, because the field 'AVN' (Application Version Number) was removed, the time format had changed and I had to rewrite the way of detecting the difference between Results Status and Workunit Status pages. Also, when a task hadn't been returned yet, the format that was displayed was different. Took me some headscratching, too.

One other script, wcgmembercmp, didn't need any rewriting, as far as I can tell. Well, one small thing, something to do with capitalization and HTML scraping.

The last script. wcglog, really didn't need any rewriting at all. In any case, if there were small tweaks, they had nothing to do with the WCG website.

For the curious, you can find the scripts at this place.

Thank you for pointing this out. I've fixed the documentation so that the first letter of the parameters is lower case as is expected by the api.

JIC, to follow up on F v f, the in progress and completed fetch script use the same line of code injecting parameter values depending on what I wanted to fetch. Tthe relevant part is in the line is "&format=xml&limit=1&offset="" i.e format in all small, no extraneous json data arrival.

The strangeness was that the in progress routine continued to work until I shut down. Today I loaded the file as my tablet is still computing 1 at a time and now In progress fetches give the 'type mismatch' (error 13) too. same as completed, the first record is malformed, the following are all fine. Help says "Cause: The variable or property isn't of the correct type. For example, a variable that requires an integer value can't accept a string value unless the whole string can be recognized as an integer."
As noted before, a non-numeric value arrives at the beginning of the first record. That's fine until that first record gets read into the table.

Anyway, I wish everyone good luck in their persevering.

Auf Wiederhören

PS MIP will have known very long before the crunching community what was going to happen with WCG. A forced eye opener I'm sure as to revisiting the operating cost of a distributed computing effort versus a private cluster and keeping their raw data results under the hood. Krembil must have figured out the operating cost too, (did BM offer a sweetener to make this happen?). Something has to pay for this and keep it running and turn this into a win for them. Meanwhile my electricity kwh cost quadrupled. I have no sponsor, no win here.