Grants.gov is the United States government’s single portal for finding and submitting applications for federal discretionary grants, used by more than 26 federal grant-making agencies. Applicants interact with it through standardised SF-424 forms, submission is gated by an Authorized Organization Representative (AOR), and the platform is now mid-migration to a rebuilt system called Simpler.Grants.gov — a shift that changes how institutional grants-management systems should integrate with it.
Grants.gov is the federal government’s centralised system for posting funding opportunities and receiving grant applications electronically, replacing the paper- and agency-specific submission processes that predated it. For research administrators, sponsored-programs offices, and developers building or maintaining integrations with campus grants systems, three structural elements matter most: the SF-424 form family a given opportunity requires, the AOR role that authorises final submission, and the ongoing Simpler.Grants.gov modernisation that is changing both the search experience and the underlying API.
- What is Grants.gov and who uses it?
- How do SF-424 form families work?
- What do AOR and other Grants.gov roles authorise?
- What is changing under Simpler.Grants.gov?
- Common questions about Grants.gov
- Implications for institutional grants management
What is Grants.gov and who uses it?
Grants.gov is the U.S. federal government’s shared portal for posting funding opportunity announcements and accepting grant applications on behalf of federal agencies. It does not award funding itself — each agency (NIH, NSF, HHS, USDA, and dozens of others) retains its own review, award, and post-award processes, but Grants.gov standardises the front door.
Applicant organisations include universities, non-profits, state and local governments, and other entities eligible under a given opportunity’s SAM.gov Assistance Listing. Before an organisation can submit through Grants.gov it must hold an active registration in the System for Award Management (SAM.gov), which in turn issues the Unique Entity Identifier used to link an institution’s Grants.gov account to its legal registration.
How do SF-424 form families work?
The Standard Form 424 (SF-424) is not a single document but a family of forms. Grants.gov organises SF-424 forms into distinct “families,” and the specific family attached to a funding opportunity determines which forms an applicant must complete. Choosing the wrong family — or mixing forms across families — is one of the most common causes of a rejected submission.
| Form family | Typical use case | Representative forms |
|---|---|---|
| SF-424 Individual Family | Applications submitted by an individual rather than an organisation | SF-424 (Individual) |
| SF-424 Short Organizational Family | Opportunities requiring only the core organisational forms | SF-424, SF-424A, SF-424B |
| SF-424 Mandatory Family | Announcements that exclude optional/discretionary forms | SF-424 Mandatory, SF-424A, SF-424B |
| SF-424 (Research & Related) Family | Research and research-related grants, used heavily by NIH and NSF | SF-424 (R&R), R&R Budget, R&R Other Project Information |
The Application for Federal Assistance (SF-424) itself — the cover form common to every family — captures applicant identity, the type of submission, the Assistance Listing number, project dates, and the certifying official’s information. Agencies publish family-specific instructions PDFs alongside each announcement; the family named in the opportunity’s application package is binding, not a suggestion.
What do AOR and other Grants.gov roles authorise?
The Authorized Organization Representative (AOR) is the Grants.gov role with legal authority to bind an institution to the terms of a grant application. An AOR’s electronic signature at submission certifies that the application is accurate and that the institution accepts the compliance obligations attached to the award — it is a legal act, not an administrative formality.
Grants.gov Workspace assigns several distinct roles, and only some of them can actually submit:
- Standard AOR — can submit applications for Workspaces where they are added as a participant.
- Expanded AOR — can submit applications and also assign roles to other users within the organisation.
- Workspace Manager — can create and manage Workspaces and add participants, but cannot submit unless also holding an AOR role.
- Workspace Participant — can edit forms within a Workspace but cannot submit the final package.
Institutions should designate more than one AOR. A single point of failure on submission authority is a recurring cause of missed deadlines when one authorised individual is unavailable during a submission window.
What is changing under Simpler.Grants.gov?
Simpler.Grants.gov is the public modernisation effort rebuilding Grants.gov’s search, application, and API layers. Unlike most federal system rewrites, the project publishes its roadmap and source code in the open, giving institutional developers visibility into upcoming interface and API changes before they ship — a genuine information-gain point for integrators, since legacy Grants.gov offered no comparable public build-in-progress transparency.
For administrators, three concrete changes are already live or in active rollout:
- A rebuilt search experience is now the default way to find opportunities, replacing the legacy search as the primary discovery interface.
- Applicants can begin work on an application before SAM.gov registration is fully verified, addressing a long-standing bottleneck where registration delays stalled application starts — though an active SAM.gov registration is still required at final submission.
- Redesigned budget forms with automated calculations are being piloted with a limited set of partner agencies, ahead of wider rollout.
The legacy system-to-system (S2S) web services that many campus grants-management platforms integrate against — including the AOR authentication and application-submission endpoints — remain the production interface today. Simpler.Grants.gov’s public roadmap describes a phased, multi-year transition, with the legacy platform and its S2S services staying operational in parallel until agencies complete migration. Integrators should track the project’s public GitHub repository rather than assuming a single cutover date, since the rollout is opportunity-by-opportunity and agency-by-agency, not a single-day switch.
Grants.gov also maintains a separate Forecast record type, listing anticipated funding opportunities before their formal Notice of Funding Opportunity is posted. Sponsored-programs offices use forecast records for advance internal planning — assigning a prospective AOR, drafting budget justifications, and pre-clearing institutional sign-off — well ahead of the compressed timelines that follow formal posting.
Common questions about Grants.gov
Is Grants.gov a legitimate site?
Yes. Grants.gov is the official U.S. federal government portal for discretionary grant opportunities, operated on behalf of federal grant-making agencies. Its domain ends in .gov, and legitimate opportunities always link back to grants.gov or an individual agency’s .gov domain — never to third-party payment requests.
Who is eligible for Grants.gov grants?
Eligibility is set per opportunity, not by Grants.gov itself. Most funding opportunities are restricted to organisations — universities, non-profits, and state, local, or tribal governments — rather than individuals, and each announcement specifies its own eligibility criteria under its Assistance Listing.
What does an Authorized Organization Representative do?
An AOR is the individual an institution designates with legal authority to certify and submit grant applications on Grants.gov. Submitting as AOR is a binding act: it certifies the application’s accuracy and commits the institution to the award’s compliance terms if funded.
What does Simpler.Grants.gov change for institutions?
Simpler.Grants.gov replaces the legacy search interface, lets applicants start work before SAM.gov verification completes, and is piloting redesigned budget forms — while keeping legacy system-to-system integrations running in parallel during a multi-year, phased migration.
Implications for institutional grants management
For offices running Cayuse, InfoEd, Kuali Research, or a comparable campus system, the practical takeaway is not to wait for a single “go-live” date. Grants.gov’s S2S web services (opportunity search, AOR authentication, application submission) remain the production integration surface, and Simpler.Grants.gov’s REST-based API is rolling out opportunity-by-opportunity rather than as a full replacement on a fixed date.
Three actions reduce integration and compliance risk during this transition. First, maintain at least two active AORs per institution to avoid a single point of failure at submission time. Second, verify the SF-424 form family named in each opportunity’s application package before form-mapping in an internal system, rather than assuming continuity with a prior award from the same agency. Third, track Simpler.Grants.gov’s public roadmap directly rather than relying on secondary summaries, since the migration timeline is agency-dependent and subject to change.
As Simpler.Grants.gov’s API-first architecture matures, institutions that have kept their internal grants systems loosely coupled to the legacy S2S endpoints — rather than hard-coding against them — will have the smoother migration path when agencies move their opportunities onto the new platform.
