Documento, página e trecho que sustentam o objeto
Entrega o **parágrafo** de documentos ASSOCIADOS ao objeto, com protocolo, link da fonte e as páginas onde ele está. Página é o que separa citação de verificação: sem ela, "está no relatório" manda o leitor procurar em 300 páginas. **O QUE ISTO NÃO É.** A ligação é documento ↔ OBJETO, resolvida por cd_cvm, CNPJ do emissor, ISIN ou ticker. Ela NÃO prova uma aresta nem uma medida específica: um documento da companhia aparece aqui inteiro, e não porque contenha a afirmação que você está conferindo. Para saber qual fonte sustenta uma relação, leia `source` na própria aresta. `excerpt` é o TEXTO DO DOCUMENTO, não resumo nosso. COBERTURA: a ponte documento↔objeto é recalculada a cada noite contra o spine de identidade, com gate de volume e cobertura — ela não pode esvaziar em silêncio. Medido em 17/08/2026: **195.266 de 196.504 documentos do acervo (99,4%)** resolvem para pelo menos um objeto. Objeto sem documento indexado responde vazio, e isso é ausência de documento, não falha de resolução. A ordem é a de ENTRADA no acervo, do mais recente para trás — **não** é relevância. Para relevância existe a busca semântica, que é outra superfície. O recorte é por DATA (`from`/`to`). Não há filtro por categoria de documento de propósito: medido, ele fazia a consulta varrer o acervo inteiro da empresa atrás de linhas que podem não existir, e a chamada expirava. Filtro que sempre expira é pior que filtro ausente.
In: header
Path Parameters
Query Parameters
1001 <= value <= 1000Data de referência mínima do documento.
^\d{4}-\d{2}-\d{2}$Data de referência máxima do documento.
^\d{4}-\d{2}-\d{2}$Como interpretar o id recebido.
auto(default) — como REFERÊNCIA publicada: id fundido resolve sozinho para o sucessor (comredirected_frompreenchido) e id cindido responde 409 com a lista.exact— como o id do objeto que existe HOJE: nenhum histórico é consultado, e o id ou responde ou é 404.
Quando você precisa de exact: numa cisão, um dos sucessores é o PRÓPRIO id pedido — o ramo que ficou com a chave de nascimento herda o identificador. O 409 manda consultar cada sucessor, e consultar esse cairia no mesmo 409. exact é o endereço dele. Serve também para desligar o redirect automático de fusão quando você quer saber se o id que guardou ainda é o id de alguma coisa.
"auto""auto" | "exact"Response Body
curl -X GET "https://api.databolsa.com/v1/objects/string/evidence?cursor=string&limit=100&from=string&to=string&resolve=auto"{
"data": [
{
"protocol": "string",
"source": "string",
"url": "string",
"category": "string",
"type": "string",
"reference_date": "string",
"filed_at": "string",
"page_start": 0,
"page_end": 0,
"heading": "string",
"excerpt": "string"
}
],
"meta": {
"next_cursor": "string",
"count": 0,
"total": 0,
"subject": {
"property1": "string",
"property2": "string"
},
"uncovered_reason": "string"
}
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string"
}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`.
As MEDIDAS do objeto, no último valor publicado
O mapa de `aspects` diz onde olhar; isto diz quanto é. Uma chamada devolve todo número que a base tem sobre o objeto — múltiplos e margens de uma companhia, cota e patrimônio de um fundo, inadimplência e cotistas de um FIDC — cada um com a data-base em que foi apurado. **Leia `unit` antes de comparar qualquer coisa.** `ratio` é fração (0,08 é 8%) e `pct` é percentual (8,0 é 8%); as duas escalas convivem no mesmo produto porque as fontes publicam assim. `dy_12m` de ação é fração, `fii_dy_12m` de FII é percentual. **`as_of` é por medida, não da resposta.** Preço é diário, indicador é trimestral e informe de FIDC é mensal: alinhar as datas na leitura inventa simultaneidade que não existe. E `series` diz a qual classe de ação a medida pertence quando `grain` é `paper` — PETR3 e PETR4 têm P/L diferente, e somar classes é a pergunta errada. Para a série de qualquer uma delas, passe o `name` em `getObjectHistory`. **`at` corta em POINT-IN-TIME**: devolve o último valor que já ERA PÚBLICO naquele dia, em vez do mais recente de hoje. É o que separa reconstituir uma decisão de junho de olhar o balanço de agosto. **Leia `availability` antes de usar `at` para backtest.** Onde ela é `filed` a fonte publica data de entrega, `available_at` vem preenchido e o corte exige as duas coisas — já entregue E com data-base até o dia. Isso importa: 21.591 das 21.949 linhas de indicador são entregues DEPOIS da data-base, com atraso mediano de 43 dias. Onde ela é `unknown` (informe mensal de FII, p. ex., que não traz data de entrega na fonte) o corte é só pela data-base e o atraso de divulgação continua de fora — não chame isso de point-in-time. Prova documental com data de protocolo é `getObjectEvidence`.