Hmm, I thought I had something there… my test “poisoned” problem user, george21, was at TL0. So I changed him to TL1 and then it worked. Ok! Maybe that’s it! So then I changed george21 back to TL0… and now he is no longer “poisoned”-- he can make the API call even as TL0.
Now I’ll run my import script again, and aha. Now george21 is throwing the 500 error in the import script. And when I try in Insomnia, it fails. So now I’ll put george21 back to TL1 and… yes, he can run the HTTP call.
So here’s what I seem to be able to reproduce:
- If a series of API calls are made (?) it somehow causes a subsequent API call to fail with a TL0 user.
- Changing the TL0 user to a TL1 allows the API call to get through.
- And strangely, then changing that same user back to TL0 still allows the API call to get through.
- Running the script again is fine until it once again fails with another TL0 user.
Note that:
- As far as I know all minimums etc for TL0 have been raised (i.e. I have tried to remove every block that would prevent a TL0 user from posting), and
- Even if this is an issue with some kind of internal rate limit for TL0 users, the API shouldn’t be throwing a 500 and putting a SQL error in the error log. So I think we can say at this point there is definitely a bug in there somewhere.
Yeah, um, I know, and I’ve gone through why I’m not writing my own import script (based on the examples given) like four times already. 
Thus my change of approach.
And in the meantime, I’m continuing to contribute here to try to help find and fix this bug. Today it’s impacting my import script. Tomorrow it could be some important script you have on your site that needs the API…