Mudanças no calendário

GET

/calendar/changes

Lista as versões de eventos do calendário que mudaram depois de since. Use esta rota para manter uma cópia local do calendário em dia sem recarregar tudo. O passo a passo está em Manter uma cópia local sincronizada.

Acesso

Este endpoint exige o escopo @calendar/changes/list na chave de API.

Parâmetros de requisição

Parâmetro	Local	Descrição	Obrigatório
since	Query	Data e hora ISO 8601. Retorna as mudanças depois deste instante. Use o metadata.next_since da chamada anterior. Sem fuso, o valor é lido como UTC.	Obrigatório
limit	Query	Mudanças por página, somando as duas listas, de 1 a 10000. Padrão: 1000.	Opcional

Resposta

Código	Descrição
200	Retorna as mudanças.
400	since ausente ou inválido, ou limit fora de 1 a 10000.
401	Não autorizado.
403	A chave não tem o escopo @calendar/changes/list.

Formato da resposta

Campo	Tipo	Descrição
data.removed[]	array	{id, removed_at} das versões que deixaram de valer depois de since: canceladas, reapresentadas ou que saíram da fonte.
data.updated[]	array	{id, updated_at, tickers} das versões ainda vigentes cujos tickers mudaram depois de since.
metadata.next_since	string (ISO 8601)	O since da próxima chamada.
metadata.full_resync	boolean	true quando é preciso recarregar o calendário inteiro. As listas vêm vazias.

Cada lista é ordenada por instante e id. A rota não lista eventos novos: eles vêm de GET /v2/calendar.

Paginação

As mudanças são ordenadas por instante (removed_at ou updated_at) e cortadas em limit. metadata.next_since é o instante da última mudança retornada ou, quando nada volta, o próprio since. Uma página nunca termina no meio de mudanças com o mesmo instante, então pode trazer menos que limit mesmo quando há mais. Chame de novo até as duas listas virem vazias.

Atraso de 2 minutos

A rota só retorna mudanças gravadas há pelo menos 120 segundos, e metadata.next_since nunca passa de agora − 120 s. Isso evita que o cliente pule uma gravação ainda em andamento. Uma mudança aparece na primeira consulta feita 2 minutos ou mais depois dela.

Recarga completa

metadata.full_resync vem true quando since tem mais de 90 dias (as versões removidas são arquivadas depois de 90 dias) ou é anterior à última reconstrução do calendário. Nesse caso, recarregue o calendário com GET /v2/calendar e continue a partir de metadata.next_since.

Exemplo

curl --request GET \
  --url "https://data.partnr.ai/v2/calendar/changes?since=2026-10-16T03:00:00.000Z" \
  --header "Authorization: Bearer SUA_API_KEY"

{
  "data": {
    "removed": [
      { "id": "6a8f0c2e9b1d4e7f8a2b3c4d", "removed_at": "2026-10-16T09:12:44.120Z" }
    ],
    "updated": [
      { "id": "6a900d3fac2e5f80913c4d5e", "updated_at": "2026-10-16T09:12:45.003Z", "tickers": ["AXIA3"] }
    ]
  },
  "metadata": { "next_since": "2026-10-16T09:12:45.003Z", "full_resync": false }
}