#identity

Live EVM on-chain data for Matchain (chain id 698) — the BNB-Chain-secured Layer-2 focused on decentralised identity and social, where gas is paid in BNB — served directly from the public Matchain JSON-RPC with server-side resilience. The status endpoint returns the chain and network id, the latest block height and the node client version. The block endpoint returns a block by number (or the latest) with its hash, parent hash, timestamp, transaction count, gas used and gas limit, miner and size. The gas endpoint returns the current gas price in both wei and gwei. The balance endpoint returns the BNB balance and outgoing transaction count for any address, converted from base wei (18 decimals) into whole BNB with exact big-integer scaling. Every figure is read live from the chain over JSON-RPC — nothing bundled or modelled — behind a short server-side cache with keep-warm so the feed stays fast and fresh. Ideal for explorers, wallet and dashboard tooling, gas trackers, address monitors and analytics apps across the Matchain identity and social ecosystem. Live keyless upstream. 5 endpoints.

api.oanor.com/matchain-api

Real-time on-chain data for cheqd (chain-id cheqd-mainnet-1), a Cosmos-SDK Layer-1 purpose-built for decentralised identity, verifiable credentials and trust registries, with CHEQ as its native coin (base denom ncheq, 9 decimals), secured by delegated proof-of-stake. The status endpoint returns the chain id, latest block height and time, proposer and node application version so you can confirm the chain is live and producing blocks. The validators endpoint returns the full bonded validator set — each moniker, operator address, stake in CHEQ, commission rate and jailed flag — sorted by stake, plus the total bonded and not-bonded CHEQ. The supply endpoint returns the total CHEQ supply (in CHEQ and base ncheq), the bonded amount and the bonded ratio. The governance endpoint returns the most recent on-chain governance proposals with title, status and voting window. The meta endpoint documents the chain, denom and decimals. Reads a live cheqd Cosmos-SDK LCD node directly (with mirror fallback), so values are current to the latest block. Live, nothing stored. 5 endpoints. This serves chain-level staking, supply and governance data; for DID documents or credential resolution use a dedicated cheqd resolver API.

api.oanor.com/cheqd-api

Read the Tezos Domains naming service live from the public TzKT indexer — no key. Tezos Domains maps human-readable .tez names to Tezos addresses, the way ENS maps .eth names on Ethereum. None of the Tezos on-chain, governance, baker, smart-rollup or FA-token readers expose the naming layer; this opens it. Browse the most recently active .tez domains with their owner address, the address they point to, registration level and expiry; forward-resolve a .tez name to the address that owns it (how a wallet turns "alice.tez" into a tz1 address); and reverse-resolve any Tezos address to the .tez names registered to it (an address can own several). The identity / naming layer for Tezos wallets, explorers, payment UX and analytics. Distinct from the Tezos on-chain reader, the self-amending governance reader, the baker reader, the smart-rollup reader and the FA-token registry. Live from the indexer; short cache only.

api.oanor.com/tezosdomains-api

Live cryptographic social-identity lookup from Keybase — no key, nothing cached. Keybase links a person's identities together with public-key cryptography, so this answers "who is this account, really, and what else are they?". The user endpoint takes a Keybase username and returns the profile (full name, location, bio, picture), every verified identity proof — the Twitter, GitHub, Reddit, Hacker News, Mastodon, website and DNS accounts that user has cryptographically proven are theirs — plus their on-file cryptocurrency addresses (Bitcoin, Zcash and more) and PGP key fingerprint: Keybase user "chris" resolves to Chris Coyne in Maine, with proven twitter/github/reddit @malgorithms and a Bitcoin address. The lookup endpoint runs the reverse — give it a GitHub, Twitter, Reddit or Hacker News handle, a domain or a PGP fingerprint and it finds the Keybase user who proved it, so a bare GitHub handle resolves to a full verified identity. The proofs endpoint returns just the connected-accounts graph and crypto addresses. This is the identity-verification and social-graph layer for any trust, onboarding, anti-impersonation, social or crypto app — proven links, not claimed ones. Live from Keybase, nothing stored. Distinct from single-platform profile APIs — this is the cross-platform proven-identity graph. 4 endpoints.

api.oanor.com/keybase-api

Canonicalize email addresses so you can deduplicate accounts and catch different aliases of the same inbox. The normalize endpoint lower-cases the address and applies provider-aware rules: it strips the dots from Gmail and Googlemail local parts (because Gmail ignores them) and maps googlemail.com to gmail.com, removes +tag sub-addressing for Gmail and the many providers that support it — Outlook, Hotmail, Live, iCloud, Fastmail, Proton, Yandex, Zoho, GMX and more — and, by default, for every domain so duplicates never slip through, while reporting exactly which changes it made and which provider it detected. The compare endpoint normalizes two addresses and tells you whether they resolve to the same mailbox. Everything is computed locally and deterministically, with no DNS or network calls, so it is instant and private. Ideal for sign-up and registration dedup, fraud and abuse prevention (one person, many aliases), CRM and mailing-list hygiene, and merging customer records. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This normalizes addresses for comparison; to verify that an address actually exists and can receive mail (MX, disposable, role accounts) use an email-verification API.

api.oanor.com/emailnormalize-api

Turn an email address into its Gravatar avatar and public profile. Pass an email and the service normalises it, computes the MD5 and SHA-256 hashes Gravatar uses, builds a ready-to-use avatar URL, checks whether a custom Gravatar actually exists, and fetches the public profile when present — display name, username, profile URL, location, about text, linked accounts and photos. A dedicated avatar endpoint builds just the image URL with full options: size (1-2048), a default image (identicon, monsterid, robohash, retro, mp, blank, 404, or your own URL), rating and force-default. Ideal for user-profile enrichment, comment systems, contact cards, team pages and onboarding — showing a real avatar from nothing but an email. A Gravatar lookup — distinct from deterministic avatar/identicon generation (avatar), which renders a brand-new image from a seed rather than fetching the avatar a person actually chose. No upstream key, no cache.

api.oanor.com/gravatar-api

Inspect any OpenID Connect / OAuth 2.0 provider. Pass an issuer (a domain, an issuer URL, or the full discovery URL) and the service fetches the provider's discovery document at /.well-known/openid-configuration, parses every endpoint — authorization, token, userinfo, jwks, registration, end-session, introspection, revocation and device-authorization — together with the supported scopes, response types, grant types, ID-token signing algorithms, PKCE methods and claims, then fetches the JWKS and summarises its signing keys (count, algorithms, key types and key IDs), and reports a validity check with any issues. A second endpoint fetches and summarises any JSON Web Key Set on its own. The request is made server-side and private/internal targets are refused (SSRF-guarded). Built for SSO and OAuth/OIDC integration, identity-provider configuration debugging (Auth0, Okta, Keycloak, Azure AD, Google), security review and monitoring of signing-key rotation. An OIDC discovery / JWKS inspector — distinct from the JWT toolkit (jwt), the security.txt parser (securitytxt) and the HTTP security-header grader (secheaders). No upstream key, no cache.

api.oanor.com/oidc-api

ORCID as an API — the global researcher identity registry, powered by the ORCID Public API. An ORCID iD (for example 0000-0002-1825-0097) uniquely and persistently identifies a researcher across journals, funders, universities and the entire scholarly record. Search more than 15 million researchers by name, institution, keyword or external identifier using rich Solr field syntax, getting each match's ORCID iD, name, other names and affiliated institutions; read a researcher's public profile including their published and credit names, biography, research keywords, country, personal and lab websites and external identifiers such as Scopus Author ID or ResearcherID; list the works they have claimed on their record with each work's title, type, publication year, journal and DOI; and trace their employment and education affiliations with the organization, role, department and dates. Ideal for research-information systems, author disambiguation, institutional reporting, scholarly tooling and academic search. ORCID iDs come from search results or are supplied directly by the researcher. Data is the public portion of ORCID records (CC0). For the scholarly works and citation graph see the OpenAlex API; for DOIs and journal metadata the Crossref API.

api.oanor.com/orcid-api