Explorer

The Filedgr Explorer is the public face of the platform. It lets anyone look up a vault, a transaction or a file hash and confirm what was notarized, without a Filedgr account and without trusting you.

Explorer: explorer.filedgr.network
Web app: app.filedgr.network

Publishing a vault

Nothing is public by default. Every vault resolves to a publication level, and until you raise it, the Explorer will not show the vault at all.

Level	What the public sees
`HIDDEN`	Nothing. The vault does not appear in the Explorer
`ON_CHAIN_ONLY`	The on-chain record — hashes, transactions, timestamps — with names and other identifying detail stripped
`FULL_NAMES`	The on-chain record plus human-readable names

The level is resolved in this order: the vault's own publication row, then your entity's default, then HIDDEN.

POST   /publications                  body: {"vault_id": "...", "publication_level": "FULL_NAMES"}
DELETE /publications/{vault_id}       unpublish a single vault
PUT    /publications/entity-default   body: {"publication_level": "ON_CHAIN_ONLY"}

All three return 204 No Content, and all three are authenticated as your entity.

note

ON_CHAIN_ONLY is the useful middle ground: a counterparty can verify that a file was notarized and when, without learning what you called it or who else holds permissions.

The public API

The Explorer's read API is unauthenticated and lives on its own host, https://explorer-api.filedgr.network — not api.filedgr.network. It only ever returns what the publication level allows.

Verify a file hash

The endpoint most integrations want. Give it a hash, get back what the platform knows about it:

curl -X POST "https://explorer-api.filedgr.network/verify/file-hash" \
  -H "Content-Type: application/json" \
  -d '{"hash": "0xcdcd...cd"}'

Search

curl "https://explorer-api.filedgr.network/search?q=<term>&type=<type>&ledger=<ledger>"

type and ledger are optional filters. No results comes back as {"items": []}.

Everything else

Endpoint	Returns
`GET /vaults/{vault_id}`	Vault detail
`GET /vaults/{vault_id}/streams`	Its streams
`GET /vaults/{vault_id}/attachments`	Its data attachments
`GET /vaults/{vault_id}/permissions`	Who holds access
`GET /vaults/{vault_id}/signatures`	Signatures on the vault
`GET /vaults/{vault_id}/timeline`	Ordered history of the vault
`GET /streams/{stream_id}`	Stream detail
`GET /streams/{stream_id}/attachments`	The stream's attachments
`GET /attachments/{attachment_id}/files`	Files inside an attachment
`GET /signatures/by-hash/{file_hash}`	Signatures over a file hash
`GET /signatures/by-wallet/{wallet_address}`	Everything a wallet has signed
`GET /signatures/{signature_id}`	One signature
`GET /transactions/{tx_hash}`	Transaction detail
`GET /transactions/{tx_hash}/related`	Records anchored by the same transaction
`GET /assets/{asset_id}`	Asset detail
`GET /assets/{asset_id}/permissions`	Asset access
`GET /entities/{entity_id}`	Entity detail
`GET /entities/{entity_id}/vaults`	An entity's published vaults
`GET /activity`	Recent public activity
`GET /stats`	Platform-wide counters
`GET /stats/ledger/{ledger}`	Counters for one ledger

Linking a recipient straight to the proof

For a specific counterparty, a proof package is usually a better fit than publishing: it is scoped to the files you choose, expires, and can be download-limited — where publishing is open to everyone, indefinitely.

Use the Explorer when you want the record to be publicly checkable, and a proof package when you want it checkable by one recipient.

Next steps

Proof Packages — shareable, time-boxed evidence bundles
Signatures — how a file hash gets anchored in the first place
API Reference

Publishing a vault​

The public API​

Verify a file hash​

Search​

Everything else​

Linking a recipient straight to the proof​

Next steps​