359 Sources, One Request Format: The NeuralVerge Data Catalog

A data catalog API is one set of lookups behind one account, one authorization header and one request style, so adding a new kind of data means picking another entry from a list instead of starting another vendor integration. The NeuralVerge catalog lists 359 sources: company registers, startup and funding profiles, marketplaces, reviews, contact enrichment and social profiles. This article shows how a request works, what a real response looks like and where the limits are.

The short version

• —What it is. 359 lookups reachable the same way over REST and MCP, each returning typed, named fields inside the same outer envelope. The 359 counts source entries in the catalog definition, which are lookups, not publishers: a company lookup and a filings lookup for one register are two entries.
• —Who it is for. Teams and agents whose workflow crosses domains, such as a register, then a profile, then a contact, and do not want a contract and parser per hop.
• —What it costs. Points from your monthly plan. Most entries are 1 point per returned result or 5 points per lookup; plans run from $50 for 50,000 points, and the pricing page is the source of truth.
• —Where to read the details. Each page in the source catalog is the reference for that entry's input, fields, price, sample response and known gaps.

What a data catalog API is

The phrase gets used loosely, so it helps to place it against the three things it is most often confused with.

Versus a single-vendor data API

A single-vendor API gives you deep access to one dataset, which is right when that dataset is the whole job. It stops being enough when a workflow needs a fact from a second domain: a company profile, then the legal entity, then a verified email. Each hop is another contract, key, response format and set of limits.

A catalog turns those hops into entries on one list. The coverage of a single entry may be narrower than a specialist vendor's full product, so check it against your own requirement. In exchange you get one account, one bill and one shape of request.

Versus a scraping tool

A scraping tool fetches pages and hands you the content. You still write the parser, maintain it when the page changes and decide what the fields mean. With a catalog source you name the lookup, send the inputs and receive named, typed fields, with the upkeep behind the source rather than in your codebase. If no entry covers the page you need, a general extraction tool that turns an arbitrary page or document into fields you define is the better fit.

Versus AI research

A catalog source answers one defined question the same way every time: give me the record for this company number, search this register for this name, list the reviews for this product. AI research answers open questions. It plans several steps, reads across sources, cross-checks facts and returns a cited answer. They are two layers of the same platform. If you know which lookup you need, call the source. If you know the question but not the route, ask research.

What is inside the catalog

The 359 entries fall into six families. The counts below come from the catalog definition, grouped the way the catalog page groups them.

The second table names the providers inside each family, with example endpoints and the points the entries in that family charge. It is built from the source pages and the catalog definition, counted at the time of writing.

Entries come in repeating shapes. Most registers have a company lookup and a search. Most marketplaces have a product lookup, a search, a seller lookup and a reviews lookup. Once you know the pattern for one, you can predict the next, and that predictability is much of the point.

How a request works

Everything below applies to every source, which is why we call it one request format.

Choose the entry

You pick the source that matches the question. For a Danish company you might choose the Denmark company search to find a number, then the Denmark company lookup to read the full record. The choice is yours, or your agent's.

Send the inputs

Every entry takes a small JSON body. A name-based search takes a keyword and optional limits such as max_items. An identifier-based lookup takes the registration number or a link to the record. There is no per-source client library and no per-source authorization scheme; the request goes to the platform's REST endpoint with a bearer key. Endpoint names, parameters and defaults are in the reference at docs.neuralverge.ai, which is where they should be read, since they change more often than an article does.

The source runs

The platform reads the source at request time, so the answer reflects the source as it stands when you ask. A live read of a stale record is still a stale record: an entry is only as current as the publisher's own last update.

The response comes back in one envelope

Whatever the source, the response has the same outer structure: a session identifier you can trace, the kind of lookup that ran, an echo of the request parameters, a readable summary, a structured result and the points charged. The fields inside the structured result depend on the source, because a register and a marketplace hold different facts. That is the honest meaning of "one format": a stable outer shape, with typed, named fields inside.

You are charged in points

Every call costs points, taken from the monthly allowance on your plan. For a search the cost is usually a per-record price, capped by the limit you set. For a single-record lookup it is usually a flat price.

One real request and its response

Here is one entry taken from the catalog: the Denmark company search. It is small, it is a typical search by name and its pattern repeats across many registers. The request is the example from the source page, and the response is the captured sample from that same page, not an invented one.

The request searches the Danish register for "novo nordisk" and asks for at most two records:

curl -X POST https://api.neuralverge.ai/functions/v1/run-dk-companies-search \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"keyword":"novo nordisk","max_items":2}'

And this is the response from the sample:

{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "kind": "dk_companies_search",
  "keyword": "novo nordisk",
  "max_items": 2,
  "start_page": 1,
  "partial": false,
  "human": "# Denmark — CVR — company search\n\n- **Keyword:** novo nordisk\n- **Results:** 2 of 72 found\n- **Proxy traffic:** 153.5 KB",
  "machine": {
    "total_items": 2,
    "first_item": {
      "registration_number": "39119374",
      "name": "Anpartsselskabet af 21.08.2026 (Under frivillig likvidation)",
      "status": "Under frivillig likvidation",
      "address": "C/O Gorrissen Federspiel, Axeltorv 2, 1609 København V",
      "url": "https://datacvr.virk.dk/enhed/virksomhed/39119374",
      "company_type": "Anpartsselskab",
      "incorporation_date": null
    },
    "items": [
      {
        "registration_number": "39119374",
        "name": "Anpartsselskabet af 21.08.2026 (Under frivillig likvidation)",
        "status": "Under frivillig likvidation",
        "address": "C/O Gorrissen Federspiel, Axeltorv 2, 1609 København V",
        "url": "https://datacvr.virk.dk/enhed/virksomhed/39119374",
        "company_type": "Anpartsselskab",
        "incorporation_date": null
      },
      {
        "registration_number": "42345393",
        "name": "Filial af Novo Nordisk Finance (Netherlands) B.V.",
        "status": "Slettet",
        "address": "C/O Novo Nordisk A/S, Novo Alle 1, 2880 Bagsværd",
        "url": "https://datacvr.virk.dk/enhed/virksomhed/42345393",
        "company_type": "Filial af udenlandsk aktieselskab, kommanditakties",
        "incorporation_date": null
      }
    ],
    "total_found": 72,
    "page_count": 1,
    "blocked": false,
    "proxy_traffic_bytes": 157192
  },
  "total_points": 2
}

A few things are worth reading carefully in that output.

• —The envelope is the part that repeats across sources. session_id, kind, the echoed parameters, human, machine and total_points are the outer structure. The machine object is where this source's fields live.
• —total_found and total_items are different numbers. The register reports 72 matches for the keyword, but only two came back because the request set max_items to 2. You pay for what is returned, not for what exists.
• —The results are not filtered to active companies. The second record has the status Slettet, meaning deleted, so you can tell live entities from dissolved ones. The status is kept as the register words it, in Danish, and so are the company types.
• —incorporation_date is null here. Search results are short on purpose. The full record, including directors, owners, auditors and history, comes from the Denmark company lookup, which takes the registration number from a result like these.
• —The cost is on the response. total_points is 2: one point for each of the two records returned.

The source page for this entry, Denmark company search, lists the fields, the price and the known gaps.

A worked example: following one company

Take an illustrative case. An analyst is vetting a supplier, Acme Oy (Finland), before a contract. The steps are a sketch of how the catalog would be used, and nothing in them is a claim about a real company.

1. —Resolve the entity. The analyst searches the Finnish register by name and picks the right record.
2. —Read the full record. With the registration number in hand, the analyst reads the company lookup for the register: status, legal form, address and the other fields the register publishes.
3. —Check the filings. Where the catalog has a filings entry for the register, the analyst lists the company's documents and fetches the ones that matter.
4. —Look at the market side. If Acme Oy sells online, matching marketplace and review entries cover its listings and reviews.
5. —Find a contact. An enrichment entry can look for a verified work email for a named person at the company's domain.

Every response arrives in the same envelope. A registration number from step 1 feeds steps 2 and 3, and the session_id of each call is an audit trail. For a cited summary rather than raw records, the same question could go to AI research.

REST and MCP

The request above is one entry, and the same entry is reachable two ways. Over REST you send the curl call shown, with a bearer key and a JSON body. Over MCP, an agent calls the tool of the same name with the same inputs. Each source page lists both, and the Denmark search is run-dk-companies-search over REST and run_dk_companies_search as an MCP tool: the REST path keeps hyphens and MCP tool names use underscores.

Every source in the catalog is available both ways on the hosted MCP server, so an agent can choose a lookup directly, read the same envelope and keep the session_id for its audit trail. AI research is the exception: it is available over REST only. For connecting a client such as Claude, read the MCP setup guide. For how the shared shape works from an agent's side, see the article on MCP server data sources, which covers normalization in more depth.

What it costs, and where it stops

Points, not a subscription per source

Plans are sized in points per month: Base is $50 for 50,000 points, Core $100 for 100,000, Pro $250 for 250,000, Ultima $500 for 500,000 and Enterprise $1,000 for 1,000,000, with a custom tier for higher volumes. That works out to $1 per 1,000 points on each listed plan. The current plans and allowances are on the pricing page.

Each catalog entry has its own point cost. In the current catalog, 183 entries are priced at 1 point per returned result and 132 at a flat 5 points per lookup. The rest cost more, such as 10 or 15 points, and a few have mixed pricing. The Denmark search above is 1 point per record, so two records cost 2 points, which is $2 per 1,000 records at the plans' rate. The number that counts is on the page of the entry you use, not in this article, because prices can change.

What happens when a lookup finds nothing

This is stated per source and should be read per source. On the register pages, for example, billing is described as per record actually returned, so a search that returns nothing costs nothing. Do not assume the same holds for every entry; read the billing line of the source you plan to run at volume.

Limits worth knowing

• —Depth varies by entry. A catalog is broad by design, and a specialist vendor's product may be deeper for one dataset. Check the fields you need against the entry's documented fields.
• —A live read is not a verified fact. A register or profile is as current as its publisher keeps it. Keep the source URL from the response with the record.
• —Gaps are documented. Each source page lists known gaps, such as the Denmark search leaving out the registration date. Read them before you design around an entry.
• —The catalog changes. Treat 359 as a snapshot.

How to decide

Use a catalog when your work spans several domains and you want one account, one bill and one request style. Before you commit, check these:

• —Does the catalog cover the entries you need, not just the category? "Corporate registries" is a family, and your country is a specific entry. Open the page for the exact source and read its documented fields.
• —What does a miss cost? Find the billing line for the entries you will run at volume, and test with a messy list before you scale it.
• —How is the cost set? Check whether an entry is priced per result, per lookup or per run, then estimate a month of real usage in points against a plan allowance.
• —What are the known gaps? A source page that lists none deserves a question. One that lists them plainly is easier to plan around.
• —Can you reach it the way you work? Code can use REST for every entry; an agent can use the same entries as MCP tools.
• —Is your use one of these? KYB and supplier checks (resolve the entity, read the record and filings, store the register link as evidence); CRM enrichment (fill company records, find or validate a contact email); market and competitor monitoring across marketplaces; startup and investor research for deal sourcing or market maps.

Frequently asked questions

How many sources are in the catalog, and how is that counted?

The catalog lists 359 sources at the time of writing. Each entry is one lookup, such as a company record, a search or a list of filings, not one publisher. Several entries can read from the same underlying publisher, so the number of distinct publishers is smaller than 359. The catalog page is the current list.

Do all 359 sources return the same fields?

No. They share the same outer envelope and the same way of making a request, but the fields inside the structured result depend on the source, because a company register and a marketplace listing hold different facts. Fields a source does not hold come back empty rather than guessed.

What does a lookup cost?

Every lookup is priced in points, and the price is on the source's page. In the current catalog most entries cost either 1 point per returned result or 5 points per lookup, and a few cost more. Points come out of your monthly plan allowance. Whether a lookup that finds nothing is billed is stated per source, so read the billing line on the page you use.

Can I reach the catalog from an AI agent?

Yes. Every source is available over REST and as an MCP tool on the hosted MCP server, so an agent can call any entry in the catalog directly. REST takes the same authorization and request style throughout.

Is the catalog the same as AI research?

No. A catalog source answers one defined lookup and returns the same kind of result each time. AI research takes an open question, plans several steps, reads across sources and returns a cited answer. Research can draw on catalog sources, and you can also call the sources directly when you already know what you need.

Will the number of sources keep changing?

Yes, the catalog is a living list. Sources are added, and a source that stops working has to be fixed or removed. Treat the number in any article as a snapshot and check the catalog page for the current list.