Privacy Policy

The triage card is the photo door on the home page, the landlord pages under /triage/, a shared card at /c/, the outcome page at /o/, and the API at /api/triage.

• The photo. Before anything else happens, our server removes the metadata a camera writes into a photo — EXIF, XMP, IPTC and the other carriers that can hold a location. A photo that cannot be cleaned is refused rather than read. The cleaned photo is then sent to the model. From 6 October 2026 we keep the cleaned photo with the Triage Profile it made, in a private storage bucket in the United States under the profile's random diagnosis_id, never your name or email. It has no public address of its own: our site shows it, from our own servers, to anyone who has the profile's link. A caller of the API can send keep_photo: false to have the photo not kept. We also keep the hash, which lets us tell that the same photo was sent twice. Before 6 October 2026 we kept only the hash on this path, so a profile made before then has no photo.
• What you type about the problem, and which role you picked (landlord, or the one fixing it), and which experiment arm you were in. The typed text is used for the read; the stored record has no field for it.
• The answer. The engine's answer, the versions of the engine and rules that produced it, the role and the arm are stored under a random diagnosis_id that is printed on the card. That id is how you refer to a card when you write to us.
• The MCP server. The fixRAgent MCP server at https://fixragent.com/mcp, which Claude and other AI assistants use as a connector or plugin, runs this same triage and handles photos and data exactly as described in this section.
• Your email address and phone number, only if you type them into the card. Section 4 covers both.
• Your IP address is held in memory for up to an hour to enforce the per-address limit, and appears in our hosting provider's request logs. Two other doors treat the address differently: our own event store keeps the city, region and country read from it (section 2.6), and a scan of one of our printed QR codes logs the address itself (section 2.7).

The older flow ("Scan my broken item") lists parts, steps and stores for a repair.

• The photo, or photos. Your browser resizes and re-encodes each photo before upload, which drops the metadata a camera writes; we do not separately verify on the server that it is gone. The photo is sent to the model. We keep it only if you tick Keep this photo at upload, which is off unless you tick it. Section 3 says what a kept photo's life looks like.
• Your description of the problem, and a ZIP code if you enter one for local store availability.
• The result. If you are signed in, the description, the answer, the parts, steps and search terms, and a snapshot of what you saw are stored under your account. If you are a guest, the result is kept on your device in your browser's storage, and a copy of the answer — without an email address — is stored on our side.
• A thumbs-up or thumbs-down you give on an answer is stored with the answer's id and, when you are signed in, your email address (diagnosis_votes).
• Home profile and appliances you choose to save, on your device and, when you sign in, under your account.
• Free-use counters in cookies and local storage, and on our side, so the free allowance can be counted.

• Your email address, and the sign-in records our authentication provider keeps for it.
• If you choose Continue with Google, Google tells our authentication provider your name, your email address and the address of your Google profile picture. Your email address becomes your account, exactly as if you had typed it; the name and picture link stay in the sign-in record. We ask Google for nothing else: not your contacts, mail, files or calendar.
• On our pages for property managers (the property-managers, enterprise and pricing pages), Google may offer a small "Continue as" box (Google One Tap) if your browser is already signed in to Google. Google draws that box and loads it from its own server, so Google sees that you visited the page. If you tap it, the same details as Continue with Google reach our authentication provider; if you close it or ignore it, nothing is sent to us. We do not show it on the home page, the repair guides, or to someone already signed in.
• Your plan, and an identifier that Stripe assigns to you. Stripe holds your card details; we never see the card number.
• The emails that sign-in needs: confirming an address, resetting a password.
• A record of each payment: your email address, the plan, the amount and Stripe's invoice id.

• Photos uploaded through a manager's intake link (/t/…) have their location and camera data removed on our server before they are stored (a photo that cannot be cleaned is refused), and are stored in a private bucket, keyed by the manager's account and the photo's hash, up to 8 MB each, together with the resident's description, the ticket it belongs to, and whether the resident was asked about, and agreed to, the photo's use. That photo goes with the request to the people it is for: the manager and the members of their account see it in their queue and in the alerts we email them, and when the manager sends the job to a vendor, the vendor's email and the job's Triage Profile show it too. Those are private links, not listed or searchable, and anyone given one can see the photo. The box on the sticker and team pages asks one thing: whether we may also use the photo, with identifying details removed, to make fixRAgent better. It starts ticked; unticking it says no to that use only, and the photo still goes to the manager and whoever they send. Around them we keep the manager's account and its members' email addresses, the properties, units and assets the manager entered, each intake code and a log of its scans (city, country and whether the device is a phone; not the network address), and, for 24 hours, a rate-limit record keyed by the code or the network address. A resident who sends a request through that link may also give their own email address; if they do, it is stored on the ticket (pm_tickets) and used for one thing: to email them when the request changes state (section 4). They are kept until the account holder deletes them or asks us to.
• When a manager sends a request on to the vendor who does that trade for them — a plumber, an electrician — the manager types the vendor's email address and may add a name; one vendor is remembered per trade, and a new address for that trade replaces the old one. We hold that address on the manager's behalf: it is stored under the manager's account (pm_vendors), shown only to members of that account, never on a public page and never in a resident's email, and used for one thing — to email that vendor the Triage Profile (the shared card at /c/, section 2.1) the manager chose to send, sent by us in the manager's name, with replies going to the manager. That mail carries the request itself — where it is, what the resident wrote, the resident's photo and what it showed — because the manager is passing the job on. We keep a record of each such send (pm_vendor_sends): the ticket, the address, the name and trade given, which member of the account sent it, the subject line, the time, and our mail service's answer and message id. Both are kept until the manager's account is deleted or the manager asks us to remove them; a vendor who writes to us is pointed to the manager who holds their address, and we help the manager answer.
• Roof-inspection photos uploaded by a contractor through the Castagra pages are stored in a private bucket for that contractor's report, with the report's job record, and kept until the contractor deletes them or asks us to.
• An enterprise pilot that sends photos through the intake API may have the photo itself stored in our database with the request, until the pilot ends or deletion is requested.
• Property-manager pilots, the retrospective look at past work orders and a live connection to a manager's maintenance system, are described separately in section 2.10.
• A partner platform can send us the web address of a photo through an open inbound endpoint and receive a link into the triage card in return; we store that address and the platform's name (b2b_inbound_leads), and nothing about the person whose photo it is beyond what the address itself carries.
• The same table (b2b_inbound_leads) also holds each request for an API key made through the form on our developer documentation or on our enterprise page: the email address the requester gave us, the company the key is for and the name of the person accepting the API terms, what they told us they were building, the version of the consent wording they agreed to, and a pointer to the key we issued. We keep it because it is the only record of who asked us for access and why. We never store the key itself. Ask us and we will delete your request.

If you send feedback from the app, the text and the email address you give (optional) are stored, sent to Anthropic's Claude model to categorise the message and draft a reply for us to read, and emailed to us. Nothing is sent to you automatically.

• Hosting logs. Our hosting provider records the address, path, user agent and time of each request, as every web host does, and keeps them for a limited period on its own schedule.
• Cookies and browser storage. Listed in the table below. None is used for advertising.
• Product analytics. Five sinks: four tools run by other companies, and one store of our own. Google Analytics loads with the app, the repair guides and most other site pages, and records page views and interactions under Google's cookies; your IP address reaches Google as part of that request. PostHog records which step of the triage flow you reached, the diagnosis_id, the page, the role, the experiment arm, and the campaign tags you arrived with; those events never carry an email address, a photo or the text you typed. On the home page PostHog also records how you use the page: where you click and move the mouse, and repeated clicks on one spot (heatmaps); which buttons, links, fields and text you click or change, with the visible label of what you clicked but never what you type into a field; which sections came into view, how far you scrolled and whether a video played; and how fast the page loaded and responded, and whether its layout moved. PostHog also keeps a replay of visits to four pages (the home page, pricing, enterprise and get started): a recording of what the page showed and where you moved, scrolled and tapped, with everything you type into a field hidden. Replays are kept for 30 days. The pages a resident uses to report a problem (the sticker link and the intake form) are never recorded. On the app page PostHog runs only on fixragent.com; on most other site pages it runs wherever that page is loaded, except on a developer's own machine. Vercel Web Analytics loads with the app and most other site pages and reports each page view to Vercel — the page, the referring page, and the country and device type Vercel reads from the request — without a cookie; Vercel Speed Insights loads with the app page and reports to Vercel how fast that page loaded for you. Our own event store (/api/track, written to a table we run, fixr_events) receives the same funnel events as PostHog: the event name, the page, the step reached, a session id, and a device id that the app creates in your browser's storage (fixr_did) together with the date it was first seen, a visit count, the page and campaign you arrived from, your screen size, time zone and language, whether the device is a phone, tablet or desktop, your connection type and whether your browser asks for reduced data, whether the app is installed to your home screen, how many processor threads your browser reports, and a Google or Meta click identifier (gclid, fbclid) if the link you arrived from carried one — stored as part of the arrival record and used for nothing else; we do not run advertising and send nothing back to either company. The app sends these events from wherever it is served except a developer's own machine, so a preview copy of the app writes to this store as well as fixragent.com. On arrival our server adds the city, region and country it reads from your network address, and your browser type; the network address itself is not stored in that table. This store is ours — hosted by Supabase like the rest of our database — and is not shared with anyone. It is kept for as long as we operate the service unless you ask us to delete your device's rows (section 9). An older endpoint that no current page calls can record a page view (the path, the referring page and whether the device is a phone; no address, no identifier) in telemetry_events. None of these runs on the legal pages.
• Fonts and scripts from other hosts. The app loads the Inter typeface from Google Fonts and its database client library from esm.sh. Most other site pages load their stylesheet from Tailwind's CDN; the roof-report page, the repair-guide index and three guides, the reliability index and a setup page load script libraries from Cloudflare's cdnjs; the resident-intake pages load Sentry's browser script from Sentry's CDN; the QR admin page loads a library from unpkg. Each of those hosts sees the request, including your IP address, when the page loads. The legal pages load none of them. Section 6 names the company behind each host, and a check in our code repository fails if a page we serve starts loading a script, stylesheet or frame from a host section 6 does not name.
• Error reports. When something breaks on our servers, the error message, the route and the software version are sent to Sentry. Email addresses inside a message are replaced with the word [email] before it leaves; photos and request bodies are never sent. The resident-intake pages also load Sentry's browser script, which reports an error that happens in your browser on those pages, with your browser type and IP address.
• Which companies visit. On the home page and our pages for property managers and businesses (for property managers, for teams, pricing, get started, setup, developers, security, connect, and the pages on the systems we work with), a script from Apollo.io sends Apollo the page you visit and your IP address, and Apollo tells us which company that address belongs to. We have it set to name the company, never the person. It runs only on fixragent.com, and never on the app, the legal pages, the manager queue or any page a resident uses.

Some of our printed and shared QR codes point at /api/q, which looks up the code and sends you on to its destination. Each scan is logged on our side (qr_scans): the time, your network address, your browser, the page that referred you if any, the city and country read from the address, and whether the device is a phone. That log has no retention job: it is kept for as long as the link exists, or until you ask us to delete the rows for your address (section 9). A QR link can be configured to load a Meta Pixel or a Google Tag Manager tag on the way through; no link is configured that way today, and if we configure one we will name the company in section 6 first. The resident intake codes in section 2.4 keep a different log, without the address.

If your plan includes the property registry, the properties you add (name, address, notes; or address, city, state and ZIP from a spreadsheet you import) and the assets you add to them (name, type, brand, model and serial numbers, notes, and what a nameplate photo was read as) are stored under your account (properties, assets). When a roof-size estimate is run for a property, or an imported property has no roof size yet, its address is sent to Google's Maps geocoding service and the result to Google's Solar service to estimate the roof area; Google sees the address in that request.

Separately from anything you do on the site, we keep a list of trade contractors — name, email, trade, city and state — that we may email about fixRAgent, and a record of each such email (contractor_outreach_queue, marketing_outreach). If you are on that list and want off it, email legal@fixragent.com and we will remove you. The same weekly job also stores marketing text it drafts for our own business listing (marketing_content); that table holds nothing about any person. We also keep records of businesses and people we approach ourselves — prospects, the contact details we found for them and our own notes — in the same database (empire_leads, rook_leads, rook_opportunities, rook_memory, as they stood on 13 September 2026). Those records are created by us, not by the software that runs this site, so the check described in section 15 does not see them. If you are in one of them and want out, email legal@fixragent.com and we will remove you.

Writing to contractors and prospects is business development. It is a separate activity from the card and the repair tool, and it runs from its own lists. We never use the email address or phone number someone gave us on a card, in the repair tool, or through a manager's intake link to market to them or to prospect. If you ask us to stop, we take you off every list we send from and keep a note of your request so that you stay off.

A property manager can try fixRAgent in two separate phases. Each one has its own purpose and its own limits, and the first does not switch on the second.

• Phase 1: a look back at past work orders. The manager sends us up to 25 closed work orders and the intake photos that came with them. Before any model reads them, we remove residents' names, contact details and other details we do not need. We compare what fixRAgent would have said with what actually happened, and we send the manager a report. We use this material only for that pilot.
• Phase 2: a live connection. This happens only when the manager confirms it in writing, naming the platform, the account and the start date, and only after access to that platform is confirmed. While connected, and only for work orders that carry a fixRAgent card, we read what we need to measure the card against the outcome: the status history and dates, the resident's request text, the assigned vendor and trade, the line items and bill or invoice fields needed for that, and the closing note. We do not read unrelated work orders, and we do not intentionally store a resident's name or contact details in the outcome record. We write only into our own fixRAgent fields and never change a status, a vendor, a bill or a note. The manager's access key is kept encrypted, first in our database (pm_buildium_connections) and then on our own server once the connection is set up. Reading stops when the manager turns the connection off or deletes the key.

In both phases the resident information belongs to the manager, and we handle it on the manager's instructions under a signed pilot agreement, not under this policy's general terms. That agreement sets how long identified records are kept and when they are deleted, and it does not allow us to use one manager's identifiable resident or work-order data to train models for anyone else. It does allow us to create statistics that no longer identify a resident, a property or a unit. The manager is responsible for telling its residents that it uses a service like ours. Section 10 explains what a resident can do.