What we receive, who reads it, what we keep.
The page your IT and legal ask for before yes. Every line here is drawn from our published privacy policy and retention schedule, or from the measured behaviour of the software. Written to be forwarded.
The one page
Who we are
fixRAgent is made by AR Logic LLC, 1705 Nagel St, Saint Marys, OH 45885. Security and data questions go to legal@fixragent.com.
What the triage API receives
One photograph (JPEG, PNG or WebP, 1 KB to 3 MB — a phone’s HEIC is converted to JPEG in the browser before it is sent, so HEIC works everywhere a person picks a photo), the problem in the reporter's own words, and a role. Metadata is stripped from the photograph on our server before anything else happens; a file that cannot be cleaned is refused, and nothing is stored.
Who reads it
An automated image model run by Google reads the photograph, once or several times, and returns the Triage Profile. No person at AR Logic looks at a photograph on this path. Google keeps the prompt, the photograph and the answer for 55 days under its own terms.
What we keep
The engine's answer, the SHA-256 hash of the cleaned file, the versions that produced it, the role and the channel. We do not keep the photograph on the triage path.
Inside your property-management software
- You make the key in your own account and can delete it at any time. It stops working the moment you delete it.
- We write one group of fields we add ourselves, named “fixRAgent triage”. We never change a title, description, vendor, priority or status. We read back every value we write; on the recorded work orders behind the enterprise page a before-and-after read of the whole work order was equal every time.
- The photograph is read back from your system, read by the engine, and not kept. Your Buildium key is sealed at rest.
- If you remove us, the field group stays yours to keep or delete; your platform's API does not let us delete it, and we say so up front.
Where it runs
Our functions run on Vercel, our database on Supabase in the United States (US East), and the engine on Google's Gemini API. Triage Profile emails and key-request acknowledgements leave through Resend. Our own encrypted backups are written nightly to a server we operate and to an off-site store in the European Union.
Architecture
One engine. The consumer Triage Profile and the business integration call the same triage function.
Drag the diagram sideways to see the whole path.
Drawn from the served code paths (api/triage.js, the Buildium layer) and /privacy §2–§6 as served on 18 September 2026.
Sub-processors
The companies that process data on the triage and integration paths, what each receives, and for how long, as published in our retention schedule.
| Company | What it receives | Purpose | Where · how long |
|---|---|---|---|
| Google (Gemini API) | every photograph that is read, the text sent with it, and the answer | producing the read | Google's own service · 55 days |
| Vercel | the request, the photograph in flight, request logs | hosting the functions and pages | runtime logs 1 day (30 with observability) |
| Supabase | the answer, the file hash, versions, role, channel; account and connection records | our database, file storage and sign-in | United States (US East) · until deleted; daily backups 7 days |
| Resend | the email address a Triage Profile or key is sent to | email delivery | 30 days of email and log data |
| PostHog | events: page views and interactions, never a photograph | product analytics | 1 year on the free plan, 7 years on a paid plan |
| Google Analytics | page views and interactions | web analytics | up to 14 months |
| Sentry | error reports from our servers, with addresses replaced | error monitoring | 90 days for errors, 30 for logs |
| Hetzner | our own encrypted backups of the database and the code | a server we operate | the last five sets, about five weeks |
| Cloudflare (R2) | the off-site copy of that nightly encrypted set | off-site backup | European Union · 14 days |
Source: /retention as served 18 September 2026; each period was read from the company's own published page on 14 September 2026, linked there.
Uptime and status
Our own probe calls the front page and our diagnosis endpoint every five minutes and records the answer. The figure above is that record read on 18 September 2026 at 04:45 UTC: one probe in 5,125 did not answer. The status page checks the front page and the triage door from your own browser when you open it, with the time each one took, so you never take our word for it.
Every reply that stops a request names the limit it hit and carries a Retry-After computed from the clock: twenty requests an hour from one address, sixty a day on a key, and a daily ceiling on what the demo may spend on our side.
Retention and deletion
- a Triage Profile's record
- our database, under a random diagnosis_id — until you ask us to delete it
- the photograph, API path
- not kept by us; read by Google and expired there after 55 days
- your Buildium key
- sealed at rest on our side; it stops working the moment you delete it in your own account, and our sealed copy is wiped when Buildium refuses it
- our backups
- a deletion reaches every copy within about five weeks: the live row at once, the off-site copy after 14 days, the server snapshots after 7, our own encrypted sets once the last five roll over
- how to ask
- email legal@fixragent.com from the address you used, or give the diagnosis_id on the profile. We act within 30 days and tell you when it is done.
Source: /retention and /privacy §8–§9 as served 18 September 2026.
Limits you can plan around
- 20 requests an hour from one address, on every door.
- 60 reads a day on a key.
- A daily spend ceiling on our side; when it is reached the reply says so, with the time it lifts.
- Photographs up to 3 MB; larger files are refused before anything is read.
Contact
Security, data and legal: legal@fixragent.com. For a walkthrough of any of this with your IT on the call, ask on the enterprise page.