How the Hub works
The RFP Hub is an open index of funding opportunities. It republishes what programs state, under one open standard, and links every reader out to the program’s own application page. It takes no applications, holds no money, and decides nobody’s funding.
Publish your first opportunity
- Sign in. The first sign-in creates the account — there is no separate signup.
- Submit the opportunity. It waits for a Hub reviewer unless your organization is already verified.
- Get your organization verified — optional, and it is what removes the wait. A reviewer grants membership and verification. After that, your listings publish the moment you submit them.
Already listed by somebody else? Open it in the directory and claim it — a reviewer decides who owns it.
The words this site uses
- Opportunity
- The thing in the world — a grant round, a hackathon, a bounty, an RFP.
- Listing
- An opportunity as published here. Everything in the directory is a listing.
- Submission
- A listing that has been filed but not yet published. Only its submitter, its organization and Hub staff can see one.
- Namespace
- The part of an id before the colon —
acme:round-4is inacme. It names the organization a listing is published under.
The five roles
- Visitor
- Reads and applies without an account. This is most people, and the whole point of the site.
- Submitter
- Any signed-in account. Submits opportunities and edits its own. Everything it files waits for a decision — including a listing about a program you run — and five can be waiting at a time.
- Organization member
- An account a reviewer has attached to an organization. Sees everything filed in that organization’s name, published or not. If the organization is verified, its members publish into its namespace instantly and decide — approve or reject — what anybody else files there.
- Hub reviewer
- Staff, and deliberately organization-agnostic: works every queue, in every namespace, including the ones they belong to and the ones they compete with. The only role that verifies organizations, grants memberships, and settles claims and duplicates.
- Hub admin
- Everything a reviewer can do, plus the accounts themselves: who holds which role, who may create API keys, and the maintenance jobs.
Who can do what
A dot is an unqualified yes. A phrase is a real limit, and the limits are the interesting part. Every row describes what the API enforces — this page is a description of that, never a second permission system.
| Action | Visitor | Submitter | Verified org member | Hub reviewer | Hub admin |
|---|---|---|---|---|---|
| Anybody, without an account | |||||
| Read the directory and open any listing No account, and no record of who read what. | yes | yes | yes | yes | yes |
| Apply to a program Always on the program's own site. | yes | yes | yes | yes | yes |
| Download the data | yes | yes | yes | yes | yes |
| Getting something listed | |||||
| Submit an opportunity | no | yes | yes | yes | yes |
| Have more than five submissions waiting at once Five undecided at a time without one. A slot frees when one is decided. | no | no | yes | yes | yes |
| Edit a listing | no | own | own namespace | yes | yes |
| See listings that are not published yet | no | own | own namespace | yes | yes |
| Publish without review A listing whose id is in a verified organization's namespace goes live on submission. | no | no | own namespace | yes | yes |
| Approve a pending submission In its own namespace, that is the organization endorsing it, in its own name. | no | no | own namespace | yes | yes |
| Reject a submission Always with a written reason, and always under the name of whoever decided. | no | no | own namespace | yes | yes |
| Claim a listing for an organization Asks for an existing listing to move into your organization. | no | yes | yes | yes | yes |
| Hub-only decisions | |||||
| Decide a claim | no | no | no | yes | yes |
| Decide a suspected duplicate Confirm and merge into one listing, or dismiss. | no | no | no | yes | yes |
| Verify an organization The decision that turns an organization's submissions into instant publications. | no | no | no | yes | yes |
| Grant somebody membership of an organization | no | no | no | yes | yes |
| Change an account's role | no | no | no | no | yes |
| Run a maintenance job by hand Deadline sweeps, source verification, duplicate detection. | no | no | no | no | yes |
What “verified” means, and what it does not
Verification says a reviewer is satisfied that an organization’s members speak for it. It is not an endorsement of the program, a check that its amounts are real, or a statement that it is a good place to apply.
Separately, the Hub runs a low-bar anti-spam check: the application page exists and its title is about the same program. Link looks right means only that. No amount, deadline or eligibility rule here has been verified. Read the program’s own page before you spend a week applying.
Why it works this way
A verified organization decides what publishes in its own namespace — approving or rejecting whatever anybody files there. Everything past its own namespace stays with Hub staff.
Why an organization decides in its own namespace
A verified organization decides what publishes in its own namespace. Somebody outside the organization files a listing about your program; a member approves it — the organization saying yes, this is ours and it is right — or rejects it. Nobody is better placed to know.
Decisions in your organization’s name carry your name. A rejection needs a written reason, and both the reason and the handle of the member who wrote it go into the listing’s history, which anybody can read. That is the whole safeguard, and it is deliberately the only one: an organization that can quietly bury an accurate listing about itself is a problem, and an organization that has to say why, in public, under a name, is not.
Why four powers stay with Hub staff
Everything past your own namespace stays with Hub staff. Verifying an organization, granting somebody membership of one, settling a claim over who owns a listing, deciding which of two near-identical listings survives — those are the four powers that could be used to widen a namespace’s own reach, so they sit with people who have no stake in any of them. Reviewers are Hub staff rather than delegates precisely so that a reviewer decides on programs they compete with by the same rule as on programs they have never heard of.
Why five submissions at a time
An account with no verified membership can hold five submissions awaiting a decision. A slot frees as soon as one is decided — by a Hub reviewer, or by the organization the listing names.
It keeps the queue honest. A queue anybody can fill without limit is a queue where the careful submission behind forty careless ones waits weeks for a person to reach it, and the first thing that goes is the review itself. Five is enough to file a whole grants program in one sitting, and few enough that everything in the queue is something somebody meant.
The data is yours
Everything published here is available as bulk JSON and CSV exports and Atom and RSS feeds, under the same open standard the site itself uses — no scraping-required tier and no paid export.
Read the StandardThe source, on GitHubBack to the directory
How decisions are made
Every rule on this page describes what the API actually enforces; the project’s governance framework covers who gets to change those rules, what one listing is checked against before it publishes, how a proposed change to the Standard itself gets reviewed, and what happens when somebody disagrees with a decision.