Everything below authenticates with your API tokens (create them on the Tokens tab). Always include the manufacturer in queries — it measurably improves identification.
What's new
Machine-readable: GET /changelog.json (no auth). Breaking changes are announced at least 90 days ahead — in your response headers, this page, and the API spec.
Quick start — REST
One call: messy description in, canonical record out. Unknown products queue background research when your token has the research scope (spends your monthly quota).
Prefer markdown (for LLM prompts and RPA logs)? Append .md to any product URL or send Accept: text/markdown:
Batches — submit a manifest's worth at once, then poll (or register a webhook with callbackUrl):
MCP — connect your AI agents
Katalog ships a built-in Model Context Protocol server. Point Claude (Desktop, Code, or API) or any MCP client at it and your agents can resolve asset strings, read records, track research, and file accuracy feedback — governed by the same token scopes and research quota as the REST API.
Claude Desktop / Claude Code configuration:
| Tool | Scope | What it does |
|---|---|---|
lookup_product | lookup | Resolve a raw description to a record; queues research for unknowns (uses quota). |
get_product | products | Fetch a canonical record as markdown by productId. |
research_status | lookup | Poll a queued research job. |
submit_feedback | products | Report inaccurate data — lands in our human review queue. |
A typical agent flow: lookup_product("HP E45028DN LASERJET") → record markdown, or a jobId → research_status(jobId) a minute later → get_product(productId). If the agent spots a wrong value: submit_feedback.
Full API reference
Try a lookup
Paste a messy description — exactly what the API sees. Free to try: no alias learning, no research, no quota use.
Request research
Not in the catalog? Submit it for research.
Your research jobs
| Submitted | Query | State | Result |
|---|
Your accuracy reports
If a record looks wrong, report it — from a job row on the Data tab, a record view, or the API. Reports feed our re-research queue; you'll see each one move open → queued → resolved here without asking.
| When | Product | Submitted by | Field | Message | Status |
|---|
| Label | Token | Scopes | Created | Last used | Expires | Status |
|---|
| Metric | Total |
|---|
| Day | Lookups | Matched | Research jobs | Reports | Tokens |
|---|
Every lookup, research request, and accuracy report from your API keys, MCP connections, and this portal — the per-event record behind your Usage numbers. Use it to reconcile billing or trace where a specific request came from.
| When | Event | Via | Key | User | Outcome | Query |
|---|
Security & Data
Your asset list is infrastructure-revealing data. We treat it that way. Lookups against the catalog are answered entirely inside Katalog — nothing leaves our systems on a lookup. Only research jobs send data out: the asset description and an optional category hint, nothing else — routed exclusively to AI providers with zero-data-retention policies; your data is never used to train those models. When an external web-search provider is enabled (the Subprocessors table below shows what's live), it receives only product search terms our research model writes — non-product content is stripped in code before anything is sent, and every query is logged for audit. Every record you receive carries its sources, per-field confidence, and an audit trail.
What we store, and for how long
| Data | Why | Retention |
|---|---|---|
| Account details (name, contact email, salted password hash) | your login | life of account |
| API tokens — stored as a hash + display prefix; we cannot see your token secret | authentication | life of account |
| Asset descriptions you submit | lookups, research, and (on confident matches) learned aliases so repeat lookups stay free and instant | research jobs purged 180 days after completion; aliases live with the catalog record |
| Usage metrics and activity events (outcome, key id, source IP, query text truncated) | your usage dashboard, billing evidence | ~13 months |
| Audit events (who/what/when; source IP on logins) | security accountability — append-only | 24 months |
| Canonical product records | the product — a shared catalog every customer benefits from | indefinite |
Learned aliases are messy product names, not customer-identifying data. A product researched once serves every customer — that's the economic design, and it never includes who asked.
What leaves Katalog, when, and to whom
A lookup that matches the catalog leaves nothing. When you request research on an unknown product, we send the asset description and optional category hint — embedded in our own prompts — to our AI gateway. Never your identity, tokens, emails, usage data, or any other customer's data. Three layers keep that path safe:
- In code, on every request: we require providers that do not store or train on inputs.
- At the workspace level (inherited by every key): routing restricted to zero-data-retention endpoints only; prompt-injection blocking; automatic redaction of emails, phone numbers, SSNs, card numbers, and IP addresses before any prompt leaves.
- Per customer: withhold the research scope from a token and that token's queries can never leave Katalog at all.
Subprocessors
| Subprocessor | Purpose | What it receives |
|---|---|---|
| OpenRouter (+ routed AI providers) | product research | asset descriptions + category hints, under the ZDR-only guardrails above |
| Backblaze B2 | encrypted, immutable backups | nightly database backups (object-locked 35 days, write-only key) |
| Tailscale | network transport & TLS | traffic in transit |
| Cloudflare | DNS | DNS queries only |
| OVHcloud | hosting | production infrastructure |
Security posture
- Tenant isolation is structural and pinned by automated tests — not a query filter someone can forget.
- Scoped, revocable, expiring API tokens with per-token permissions and quotas; secrets hashed, never stored or displayable.
- Append-only audit trails on both the operator and customer surfaces, with per-request attribution — your own security events are on the Account tab, exportable as CSV.
- Webhooks are HMAC-signed so you can verify every callback came from us.
- MFA available on customer accounts (enforceable per account); enforced for operators.
- Backups are encrypted at rest and immutable (object-locked, 35 days). Non-production environments never receive raw data: seeds are scrubbed of credentials and PII before they leave production.
- Spend and quota caps per customer — a runaway integration can't burn your budget or ours.
Your data, your exit
- Bulk export of your data in open formats, on request and at termination.
- Account erasure hard-deletes your identity and activity records; a documented deletion path exists today.
How we handle security incidents
- Detection. Production is monitored continuously by our observability stack — metrics, logs, and synthetic probes — with push alerts to the on-call operator. Append-only audit trails on both the operator and customer surfaces mean security-relevant actions are recorded as they happen, not reconstructed afterward.
- Notification. If we confirm a security incident affecting your data, we notify your account contact by email within 72 hours of confirmation — with what we know, what we've done, and what we recommend you do. We follow up as the picture develops rather than waiting for a complete story.
- Containment and forensics. Evidence is preserved before remediation: audit trails are append-only (retained 24 months), backups are immutable (object-locked, 35 days — an attacker on our host cannot alter them), and we snapshot affected systems where feasible before rebuilding. Recovery uses provisioning-as-code plus the immutable backups.
- Scope honesty. We are a small team; what we commit to is what we can actually do, and everything above is built into the system rather than dependent on heroics. We do not have a 24/7 security operations center — we have a monitored pager, an append-only record, and infrastructure designed to be rebuilt from clean state.
Secure configuration guide
- Enable 2FA on the Account tab (TOTP; recovery codes shown once).
- Scope tokens minimally: a token without the
researchscope can never cause data to leave Katalog; read-only integrations need onlyproducts. - Set token expiry at creation (the default is 90 days) and rotate on a schedule: the Rotate button mints a replacement with identical settings and gives the old token a 24-hour switchover window — no outage, no manual re-scoping.
- IP-lock production tokens: set the IP allowlist at creation to your egress ranges (CIDR) — a stolen token is then useless from anywhere else. Note it's checked against the source address we see, so list your NAT/proxy egress IPs.
- Verify webhooks: check the
x-katalog-signatureHMAC header against your webhook secret before trusting a callback. - Watch your security events (Account tab): sign-ins, token changes, and exports, from the append-only trail.
Compliance status — the honest version
We publish what's true rather than what's expected: SOC 2 certification is not yet in place. Our posture is to complete it in the same quarter a contract requires it, and our controls are built audit-first (append-only trails, retention-by-design, scoped access). In the interim we provide an evidence pack under NDA covering the controls above. Ask — the answers are specific.
Content last reviewed 2026-07-09. Questions? Contact your account contact.
Password
Two-factor authentication …
Sessions everywhere you're signed in
| Device | IP address | First signed in | Last active |
|---|