Cookie policy
Every cookie set by rfp.co and app.rfp.co, what each one does, how long it lasts, and why there is no consent banner.
Last updated August 8, 2026
Governed by Arkansas law
This page lists every cookie RFP.co sets. There are six, all of them strictly necessary, and there are no analytics, advertising or social media cookies anywhere on either site. That is why you were not asked to accept anything when you arrived.
1. What a cookie is, and what “strictly necessary” means
A cookie is a small file a site asks your browser to keep and send back on the next request. Without them a website cannot tell that two requests came from the same person, which is why signing in to anything requires one.
Privacy law treats cookies in two groups. Ones that are strictly necessary to provide a service the user asked for need no consent. Everything else — analytics, personalisation, advertising — needs it.
The distinction is routinely stretched, so here is the test we hold ourselves to: a cookie is strictly necessary only if removing it stops a specific function the user was trying to use. Every cookie below fails to be optional under that test. None of them measures you, and none is readable by anybody else’s domain.
2. Every cookie we set
| Name | Site | What it does | Lasts |
|---|---|---|---|
rfp_sessionHttpOnly | app.rfp.co | Holds the session token that keeps somebody signed in. The token is an opaque random value; the account it belongs to is looked up on the server, and revoking a session takes effect immediately. | 30 days maximum, and expires after 14 days without use |
rfp_return_toHttpOnly | app.rfp.co | Remembers the page somebody was trying to reach when they were asked to sign in, so they land there afterwards rather than on a dashboard. | Until the sign-in completes, and at most 15 minutes |
rfp_oauthHttpOnly | app.rfp.co | Carries the one-time state and verifier for a sign-in with Google, so the response that comes back can be proved to belong to the request that started it. | 10 minutes |
rfp_plan_intentHttpOnly | app.rfp.co | Remembers which plan somebody chose on the pricing page while they create an account, so they are not asked to choose twice. | 15 minutes |
rfp_share_<id>HttpOnly | app.rfp.co | Records that somebody opening a password-protected proposal link has already entered the password, so they are not asked again on every page. | The browser session |
rfp_signed_in | rfp.co | Tells the marketing site whether the visitor has a signed-in application session, so the header offers “Dashboard” rather than “Sign in”. Its entire content is the digit 1. | Written and cleared alongside the session cookie |
Why each one is necessary
rfp_session— Without it there is no signed-in state and the application cannot be used at all.rfp_return_to— It is part of completing an authentication the person themselves started; it holds a path and nothing about the person.rfp_oauth— It is the cross-site request forgery defence for the OAuth round trip. Without it the sign-in is unsafe rather than merely inconvenient.rfp_plan_intent— It carries a plan code the person selected a moment earlier and nothing else, and it is what makes a sign-up started from pricing complete correctly.rfp_share_<id>— It is the proof of a password the recipient entered. The link itself is re-checked for revocation and expiry on every request regardless.rfp_signed_in— It authorises nothing, identifies nobody, and is readable by scripts on purpose. It is off unless a deployment sets a shared cookie domain, and the served HTML is always the signed-out state.
All of them are set as HttpOnly except rfp_signed_in, which exists to be read by a script and carries nothing worth protecting. All are Secure in production, all use SameSite=Lax, and all are host-only by default — they are not shared across subdomains unless a deployment explicitly widens them.
3. What we do not set
- Analytics cookies. There is no Google Analytics, no tag manager and no product analytics SDK on either surface.
- Advertising or retargeting cookies. RFP.co runs no advertising pixels and shares nothing with an ad network.
- Social media cookies. No embedded share widgets, no like buttons and no third-party iframes that set cookies.
- Cross-site tracking of any kind. No cookie set here is readable by another company’s domain.
This is checkable rather than asserted. Open your browser’s developer tools on any page of this site and look at the network tab: every request goes to rfp.co, app.rfp.co or our own content delivery network. There are no third-party script tags to inspect because there are none.
4. Other storage
Local storage and session storage. Not used to store personal data. The application is server-rendered and keeps its state on the server; the interface holds what is on screen and nothing that survives a tab closing.
Server-side logs. Requests are logged with an IP address, a user agent and a path for operational and security purposes. Logs are not a cookie, are not linked to advertising, and are retained on the schedule in the privacy policy.
5. Controlling cookies
Every browser lets you see, block and delete cookies, and every browser’s help pages explain how. You do not need our permission and we do not detect or discourage it.
What blocking them costs you here is exactly what §2 says: block rfp_session and you cannot stay signed in; block rfp_oauth and signing in with Google will fail safely rather than proceed unsafely. The marketing site works completely with every cookie blocked — it will simply always show you the signed-out header.
We honour Global Privacy Control and Do Not Track signals in the sense that matters: there is nothing for them to turn off, because we do not track you in the first place.
6. Changes
If we add a cookie, this page changes in the same commit. If we ever add one that is not strictly necessary, we will ask for consent before setting it — which would also mean adding the banner this page currently explains the absence of.
7. Contact
Questions: privacy@rfp.co. What we do with data beyond cookies is in the privacy policy.
See what you are not bidding on.
Connect a source, describe what your company does, and look at the opportunities that come back before deciding whether any of this is worth your time.