Hmm, pensei que já tivesse algo disso… meu usuário de teste “envenenado”, george21, estava no TL0. Então, mudei-o para TL1 e, em seguida, funcionou. Ok! Talvez seja isso! Então, mudei george21 de volta para TL0… e agora ele não está mais “envenenado” — ele consegue fazer a chamada da API mesmo estando no TL0.
Agora, vou executar meu script de importação novamente, e aha. Agora george21 está lançando o erro 500 no script de importação. E quando tento no Insomnia, falha. Então, agora vou colocar george21 de volta no TL1 e… sim, ele consegue executar a chamada HTTP.
Então, aqui está o que parece conseguir reproduzir:
- Se uma série de chamadas de API for feita (?), de alguma forma isso faz com que uma chamada subsequente falhe com um usuário TL0.
- Alterar o usuário TL0 para TL1 permite que a chamada de API seja processada.
- E, estranhamente, ao mudar esse mesmo usuário de volta para TL0, a chamada de API ainda consegue ser processada.
- Executar o script novamente funciona até falhar mais uma vez com outro usuário TL0.
Observe que:
- Até onde sei, todos os mínimos etc. para TL0 foram elevados (ou seja, tentei remover cada bloqueio que impediria um usuário TL0 de postar), e
- Mesmo que isso seja um problema com algum tipo de limite de taxa interno para usuários TL0, a API não deveria lançar um erro 500 e registrar um erro SQL no log de erros. Portanto, acho que podemos afirmar, neste ponto, que definitivamente há um bug em algum lugar.
Sim, hum, eu sei, e já expliquei quatro vezes por que não estou escrevendo meu próprio script de importação (com base nos exemplos fornecidos). 
Daí minha mudança de abordagem.
E, enquanto isso, continuo contribuindo aqui para tentar ajudar a encontrar e corrigir esse bug. Hoje, isso está afetando meu script de importação. Amanhã, pode ser algum script importante que você tenha no seu site e que precise da API…