O erro mais caro num agendamento de posts não é a API cair — é o post sair uma hora adiantado ou atrasado porque o fuso horário foi tratado errado em algum lugar. A API de agendamento do PostGate interpreta cada horário num fuso IANA explícito e trata a entrega como um processo que pode falhar e se recuperar, não como uma promessa de horário exato sem plano B.
Todo schedule carrega um timezone IANA — como America/Sao_Paulo — e os horários são interpretados nele, não no fuso do servidor. Uma agência com clientes em fusos diferentes configura cada schedule no fuso do cliente correspondente.
Alterar o timezone ou a expressão de um schedule já existente recalcula as próximas materializações a partir dali — o histórico de posts já publicados não muda, mas vale revisar o horário seguinte antes de aplicar em produção.
Um destino pode passar por retry_scheduled antes de chegar a um estado final — o PostGate reencaminha a entrega ao provedor internamente. Retentativas do seu lado só fazem sentido para falha de aceitação da API, com o mesmo Idempotency-Key.
Trocar o fuso horário de um schedule é uma alteração pontual — sem recriar o template inteiro nem perder o histórico de posts já materializados.
Ver como a API sinaliza o que é retentável/api/schedules/{id}200 OKcurl -X PATCH https://postgate.studio/api/schedules/sch_01JXYZ \
-H "Authorization: Bearer $POSTGATE_API_KEY" \
-d '{
"timezone": "America/Recife"
}'Veja como estruturar a expressão cron ou os horários de fila em agendador de posts via API.
Acompanhe o ciclo completo do post materializado na API de publicação.
Entenda quais códigos de erro são retentáveis e quais exigem ação sua na documentação de erros e retentativas.
Sandbox gratuito, documentação completa e uma API para cada rede social que os seus clientes usam.
