Qualify deeply. Apply selectively. Never lose momentum.
Once your team has decided which funders to pursue and set up a request profile for each, someone still has to open the portal, re-type the same organizational details, attach the right documents, and hope nothing was missed — for every single application. AutoApply takes over that mechanical work for the applications you've already chosen, behind a stack of real eligibility, risk, and rate checks that decide, submission by submission, whether it runs automatically or waits for a person.
The actual AutoApply dashboard
Not a mockup — worker status, session metrics, the live session viewer, and the submission queue with per-item status, captured from a running instance of the application on September 8, 2026.
Watch a submission clear the gates
Each step below mirrors a real stage in the worker pipeline (worker/queue-processor.ts).
How it actually works
AutoApply never chooses who to contact. A staff member sets up a request profile — what you're asking for, from whom, and the pitch to use — and queues it. From there, a single worker process picks up one item at a time and runs it through the same ordered set of checks every time: is any part of the platform, this domain, this funder, or this tenant currently paused; is the organization's own profile complete enough to fill a form accurately; has this organization already hit its rate limit; has another organization already used this exact funder recently; and finally, what does the risk engine think of this specific combination of funder, form, and ask amount.
Two submission channels exist depending on what the funder actually offers: a web form, filled and submitted by a stealth browser session once every gate above clears, or a plain email submission (via Resend) when a funder only publishes a contact address and no portal. Both are logged the same way in autoapply_submissions.
AutoApply also isn't the platform's only path to a funder's portal — a separate, human-approved browser-automation flow exists for application-scoped runs. The two check each other's active work on the same organization+funder pair before starting, so neither can run the same submission twice without either knowing about it.
The phrase we use internally is the one you'll see across this page: qualify deeply, apply selectively, never lose momentum. Depth comes from the readiness and risk checks below. Selectivity comes from the fact that nothing is contacted that a person didn't configure a request profile for. Momentum comes from not having to re-open the same portal by hand.
Inputs and outputs
- A staff-authored request profile: what's being asked for, the pitch, and value range
- Organization profile data: mission, EIN, address, contact, and required documents
- The funder's own portal — its form fields, login requirements, and file uploads
- Subscription tier, which sets the rolling daily submission cap
- Platform / domain / funder / tenant pause switches, set by staff or an admin
- A submission record per attempt: channel, status, timing, and confirmation data
- A risk score and the specific factors that produced it, on every routed item
- Stage screenshots (page load, pre-fill, post-fill, post-submit, or a CAPTCHA pause)
- Confirmation-email matches, with an extracted confirmation number when present
Where a person is in the loop
A person decides which funders to pursue and configures the request profile for each — that never happens automatically. From there, three separate mechanisms decide, per submission, whether a person needs to be involved before it goes out:
Risk-based routing. Ten weighted factors — a portal flagged manual-only, a legal attestation checkbox, an ask amount more than 50% above the funder's historical maximum, missing required documents, an unanalyzed or low-confidence form, and others — produce a 0-100 score. Anything scoring above 50 is routed to a manual queue before a browser session ever opens, it is never submitted automatically, and a webhook notification fires for the same "high" and "critical" band — any score above 50.
CAPTCHA and verification pauses. Benavora does not solve CAPTCHAs or identity-verification challenges. Detecting either — reCAPTCHA, hCaptcha, Turnstile, or a page containing phrases like "verify you're human" or "enter the code sent to" — stops the run immediately, captures a screenshot, and waits for a person to resolve it and resume.
Portals that require a one-time human setup. A small number of portals need a person to create and configure an account before any automated login is possible; those are surfaced as an actionable status rather than silently retried forever.
Even for a submission that clears every check, the form-filling step still requires a real, audit-logged approval record to exist before it will submit anything — there is no code path that skips straight to submission.
Quantified results
We don’t have a published submission-success rate or time-saved figure for AutoApply yet. Those numbers depend on real usage across a full grant cycle, and we’d rather show you an honest “pending” than a number we backed into. This section will be replaced with real pilot data once we have it.
What it actually connects to
- Funder web portals — via a stealth browser session, one funder at a time
- Resend — plain email submission when a funder has no portal, only a contact address
Polled every 5 minutes to match inbound confirmations back to a submission.
- Gmail — a dedicated, read-only Benavora inbox shared across all organizations
- Zoho Mail — an organization’s own connected mailbox, for orgs whose confirmations land there instead
Security and reliability
Every portal URL is validated against private and internal address ranges before a browser or a health check ever reaches it. Cross-client dedup compares organizations only as a SHA-256 hash, never a raw identity. Admins can halt automated submission at four independent levels — platform-wide, a specific domain, a specific funder, or a single organization — and every one of those pause switches is checked before an item runs. For the platform-wide security and governance model, see the Trust and Governance page.
Customer story
COMING SOON
We don’t have a published customer story for AutoApply yet. Once an organization has run it through a real grant cycle and agreed to be named, their story will go here — not a composite or hypothetical example.
FAQ
Run the free Funding Potential Scan first — a short, no-signup check of the kind of funding your organization is likely to qualify for.
See a Governed Application Run
Watch a real submission move through readiness checks, the risk engine, and approval before it ever reaches a funder's portal — on the applications your team has already chosen.