Quantos objetos existem no grafo, por tipo e por identificador
O censo: objetos que EXISTEM, por `kind`, e as chaves que apontam para eles. **Não confundir com `getObjectLinkStats`**, que conta objetos com determinada RELAÇÃO — são perguntas diferentes e responder uma com a outra erra por ordem de grandeza. Traz também quantos objetos têm chave ambígua e quantas chaves chegaram por cadeia de apelido, que é a medida de quanto o grafo depende de resolução.
curl -X GET "https://api.databolsa.com/v1/objects/stats"{
"objects": 0,
"by_kind": [
{
"kind": "string",
"count": 0
}
],
"by_subkind": [
{
"kind": "string",
"subkind": "string",
"count": 0
}
],
"ambiguous_key_objects": 0,
"keys": 0,
"by_key_type": [
{
"key_type": "string",
"count": 0
}
],
"keys_via_alias": 0,
"keys_low_confidence": 0,
"relationships": 0,
"assertions": 0,
"links": 0
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}O objeto, seus apelidos e o MAPA do que dá para perguntar em seguida
`keys` traz todos os identificadores que apontam para o mesmo objeto — é o que responde 'PETR3 e PETR4 são a mesma empresa?'. `links` é o mapa: quais relações existem para ESTE objeto, em que direção e quantas. Relação que não existe não aparece, em vez de devolver página vazia numa travessia — página vazia, para quem consulta, é a afirmação de que não há relação. **ID QUE SAIU DE CIRCULAÇÃO NÃO É 404.** Objeto se funde e se cinde — raramente, mas acontece. Com sucessor ÚNICO (fusão) esta rota resolve sozinha e devolve o objeto atual com `redirected_from` preenchido: atualize o id que você guardou. Com mais de um sucessor (cisão) responde **409** listando todos, porque escolher um por você acertaria parte das vezes e erraria o resto em silêncio. Vale igual em `listObjectLinks`, `getObjectFacts`, `getObjectHistory`, `getObjectEvents`, `getObjectEvidence` e `findObjectPaths`. **A lista do 409 pode conter o próprio id que você pediu**: numa cisão, um dos ramos herda o identificador por continuidade técnica. Para ler ESSE ramo use `resolve=exact`, que lê o id literalmente — sem ele, consultar esse sucessor voltaria ao mesmo 409 e o ramo seria inalcançável por qualquer rota. Os demais respondem pelo id deles.
O que ACONTECEU com este objeto — o ledger lido pelo grafo
O ledger de eventos existe desde antes do spine e não sabia de quem era: para pegar os eventos da Petrobras era preciso escolher entre PETR3 e PETR4 pelo `listMarketEvents`, e perder o que estivesse marcado só com o outro papel. Aqui o objeto entrega TODOS os apelidos de uma vez. **Evento é do EMISSOR, não da classe.** Um fato da companhia vem marcado ora com um papel, ora com o outro, ora com os dois — e vir marcado com os dois não o conta duas vezes aqui. Somar as consultas por ticker faria exatamente isso. **A cobertura vem do TICKER.** Há também um casamento por nome canônico exato, mas ele rende pouco e isso está medido: o ledger grava nomes curtos e às vezes truncados (`Allos`, `Anima`, `Lojas`, `Petróleo`), então só 3 de 60 casam com a razão social. Ele fica porque é seguro e pega os poucos casos de nome curto (BRAVA, BRB, HAPVIDA); afrouxar para prefixo casaria `Rio` com dezenas de empresas, e errado com confiança é pior que ausente. Na prática: **objeto sem ticker tende a devolver lista vazia**, e isso é limite conhecido, não ausência de evento. Para o ledger inteiro sem partir de um objeto, use `listMarketEvents`. Estes NÃO são eventos societários (grupamento, bonificação) — esses vivem em `listCorporateEvents`.