Build on Kindora

What's actually in it

Every number here is counted from the live database — the corpus aggregates nightly, the headline counts on a daily refresh cycle — none of them typed in by hand. They move when the corpus moves, including down.

Recounted August 20, 2026 — the timestamp is live too, so you can tell if this page ever stops tracking.

Where it comes from, and what that means for you

The spine is public: IRS Form 990 and 990-PF filings, national charity registers, and government grant portals — federal and state alike. On top of that we read funders' own websites for what filings can't tell you — which programs are open, who's eligible, when they close, and who to talk to. And we search the open web for what's being reported about a funder elsewhere — leadership changes, new initiatives, coverage that never appears on their own site — verify it, and structure it into the profile. We ingest all of it ourselves rather than reselling a third party's compilation, which is why the terms of use are ours to negotiate rather than someone else's to restrict.

Read the full source breakdown, including where it falls short →

What we build on top of the filings

A raw 990 is a tax form: a name, an address, financial totals, and grant lines whose recipients are free-typed text with no ID and no location. Nothing in it answers the questions that matter — who funds work like mine, can I approach them, what would they give. The structured layer is where those answers come from:

This derived layer — the matching, classification, and analysis, not the public records underneath — is what the Data Use Policy licenses. The underlying facts stay public, as they should; the structure is the product.

How current it is

Filings land as the IRS publishes them. Funder websites are re-crawled weekly, with new URLs discovered monthly. Public filings are structurally 18–24 months behind the year they describe — that's a property of the source, not of us, and the website layer exists precisely because of it.

Three ways in, and what each one permits

Two of these are self-serve and cover research — yours, or your clients'. The third is the only one that lets you show Kindora results to your own users. They are different rights, not different sizes of the same right, which is why volume alone never converts one into another.

Both ceilings are real and enforced: 2,000 lookups an hour and 12,000 a day, per organization. They are set where they are because the metered lane is sized for research, not for serving another product's traffic.

Send your kdra_ service key as a Bearer token to the public MCP endpoint and lookups meter at 3 per credit — roughly $21.67–$33.33 per 1,000 lookups, depending on pack size. Metered capacity covers the permitted uses above; it does not confer embedding or redistribution rights at any volume.

What needs a written agreement

Our Data Use Policy is the same for everyone, and no credit balance is a substitute for it. Each of the following needs an agreement, at any volume: redistributing Kindora data; embedding it in your product, platform or service; reselling or sublicensing it; bulk or systematic extraction, including building or improving a database, directory or search index; and using it to train models or build retrieval indexes. That last one survives termination.

Read the Data Use Policy →

Attribution

Wherever Kindora data is shown to anyone beyond your own organization or client engagement, the surface must credit "Data from Kindora (kindora.co)" with a working link, and chat or voice surfaces must name Kindora in the answer itself. Licensed integrations carry their own attribution, set in the agreement — usually "Powered by Kindora".

REST API

1,000 requests / hour per key

The REST surface is small on purpose today — public match rationale only. Funder-profile and grant-history endpoints are specified but not yet shipped, so for anything broader use the MCP endpoint, which exposes the full public toolset.