Frequently asked questions

Rindler runs the web work teams still do by hand: signing into portals to pull records, download statements, check claim or order status, and submit forms. You describe the task in plain language and it runs, on the sites you log into every day, including the ones that have no API and never will. The first pass through a site we have not seen is the work. After that the same task repeats without anybody rediscovering the site. And when something does not work, it tells you, rather than reporting success and leaving you to find out later. Founded in 2025 and backed by Y Combinator.

Teams whose day is spent inside a login-walled system somebody else controls: insurance agencies on carrier portals, billing and revenue cycle teams on payer portals, staffing coordinators in ATS and client VMS portals, and AP and AR teams on supplier and customer portals. The shape is the same everywhere. High volume, no way in except the browser, and mistakes that are expensive to unwind. If your team logs into a portal, copies what it sees into a spreadsheet or your own system, and does that a few hundred times a week, that is the work Rindler takes.

No. You describe the task the way you would describe it to a new hire, and Rindler runs it. There is nothing to install, no code to write, and nothing for your IT team to host. The people who do the portal work are the people who set up the task. Bring IT in only if your own policies require a review of who signs into what, which is a conversation rather than a project.

In plain language. "Pull the loss runs for these twelve accounts and put them in one folder" is a complete instruction. You can run a task once, or save it and put it on a schedule so it happens every Monday morning without anyone remembering to start it. Results come back as rows you can hand straight to your own system, not as screenshots somebody has to retype.

An offshore team is still people typing, so the cost grows with the volume and so does the error rate at four on a Friday afternoon. Rindler does the same task the same way at four in the morning as it does at four in the afternoon, and the cost does not climb with the count. The part teams usually care about more: when a run does not go through, you get told. You are not finding out three weeks later that forty submissions were never filed.

RPA records the exact clicks on the exact screen, so the day the portal moves a button the recording breaks and somebody has to rebuild it. Rindler works from what a screen means rather than where a button sat this morning, so an ordinary redesign is not an outage. That is why RPA struggles on portal work specifically: portals ship changes on their own schedule and never tell you they did.

Point an AI at a page and it works the screens out again on every single run, so the same task can come back differently each time, and every redesign the site ships lands on your team. Rindler works a site out once, and every run after that follows what it already knows. That first pass is the work, and it is ours. When a change is big enough to stop a task, fixing it is our job, centrally, once, for everyone on that site. The portals your team lives in are somebody else's, and they have no API and never will, so this happens in a browser either way, signed in on your own account. Those are the ones we took on, the ones that fight automation hardest, including behind a login. What comes back is the same shape of rows every run, not paragraphs somebody has to read.

It is not tied to an industry. Rindler works on the sites you log into, whatever they are. What runs today includes applicant tracking boards, bank sites, state business registries, and a catalog of public sites. Carrier, payer, supplier and VMS portals are set up per customer, which is most of what teams bring us. If your team signs into it and does the same work there every week, send us the address.

Yes, if you can reach it in a browser. That includes old internal portals and vendor systems that were never built to connect to anything else. Rindler signs in the way your team does, works through the same screens your team uses, and hands the result back as rows instead of a page to read. Every new site is set up individually and only goes live after it has been tested against the real site.

The judgment. We pull the denial, gather the attachments and put the packet in front of the person who decides. Nothing spends money or files anything unless you asked for it.

If what you want is a list of addresses, buy a feed. That market is cheap and it works. What a feed cannot give you is the filed documents on the specific counties your team works, collected inside your own access, with your own rule about what to do with each case. That is the job we take on. If the list is enough, we would rather you spent the money on the list.

Nobody yet. You would be the first. We are two engineers who took on the sites that fight back, and being first means the work gets built around your portals rather than somebody else's.

You do not need an admin to grant anything, and you do not need an engineer. If you can sign into the board and see the candidate, Rindler can read it and hand it back as rows. Yes. Setting up one board covers every client you recruit for, and reads run today. Stage moves and other writes are built for you during setup.

Yes, inside a portal your team already signs into. We build the send with you during setup, and it goes out from your own account the same way your team sends today. Two things stay yours: who is on the list, and what the message says. You approve both before the first send. It reaches only the people already in your account, the same as when somebody on your team does it by hand. Pulling contact details off a list of websites is a different job, and we chose portal work instead.

You sign in once yourself, on the real site, in a browser Rindler manages. After that the task runs without you. That is the whole difference from anything that reads a public page from the outside. Rindler works inside your own session on your own account, which is why it reaches the pages that only exist after you log in. Rindler keeps the session, encrypted with AES-256-GCM under a key scoped to your account, and not your password. For a limited set of sites you can choose, per site, to store the sign-in details instead.

Rindler signs in the way your team does, pulls the statements and transaction exports, and hands back the files. We build the statement and transaction export for the banks you name, account by account. Banking is read-only: nothing is moved, paid, or transferred. You do the first sign-in and any two-step verification yourself, and Rindler reuses that session later so the download does not need you every month. Other banks and portals are set up on request, and a site goes live only after it has been tested against the real thing.

Yes. Secretary-of-State business-registry lookups run today, and come back as rows rather than a screen to read. Give it the entity or the search you would run by hand and it returns the filing data. Court systems, permit portals, and PACER-style dockets are not in that live set; we build those for you during setup, one jurisdiction at a time, and we run each one against the real site with you before you rely on it.

Court and county records are built for you during setup, one jurisdiction at a time, and state business-registry lookups run today. Every county runs its own site and no two behave alike, which is why this is per jurisdiction rather than one switch. Send the addresses of the ones your team actually works. We go through each one with you and hold the sign-in where there is one, and we agree what comes back before it runs. What to do about a case stays your team's call.

For the most part yes, and we will not pretend otherwise. Those two are largely electronic already. Rindler is for the parts of the cycle that are not. The portal-only work is where we help: uploading medical records for a prior authorization, assembling a reconsideration on the payer's own portal because there is no standard transaction for one, chasing an appeal that has gone quiet before it ages past a timely-filing deadline, retrieving a denial letter or paper EOB the remit file never carried, and keeping provider profiles current in a credentialing system with no electronic feed at all. There is also the thin eligibility response, missing the visit limits or accumulators the front desk needed, that sends somebody back to the portal anyway. Setup is per plan and per task, because a payer's prior authorization screens are not its appeals screens. Rindler is not HIPAA certified and does not claim to be; each deployment is scoped to your BAA and HIPAA requirements, agreed with your team before it goes live.

Yes, once that supplier or AP portal is set up. These are set up on request rather than running today. A submitted invoice comes back with the document number and the accepted status, which is your proof it went through, and PO status sweeps come back as rows rather than one page per order. Most write actions on supplier portals sit in that same on-request tier, so treat a date as something we quote after seeing the portal.

Yes. We set up the sites you watch and return what is on the screen as rows, whatever the page shows. Sites like this are set up on request. The mechanism is the same one running on the live sites today: work out the screens once, test against the real site, then read rows instead of pages. Paste the address of the site your team actually watches and that is the one we set up.

A run you kick off hands back the records and any file it collected. A file a run captured comes with a download link that needs no login and expires in about 30 minutes, so it is put in front of you rather than left in a folder somebody has to go find. A scheduled run is different today: it keeps its steps and where it stopped, and where the records go next is part of what we scope before we start.

For most sites, no. You sign in yourself, and Rindler never sees the password. You log in on the real site, inside a browser Rindler manages, and Rindler keeps only the resulting session, encrypted with AES-256-GCM under a key scoped to your account. For a limited set of sites you can choose to let Rindler store the sign-in details so it can log in for you. That is opt-in, per site, and encrypted.

For most portals you keep the password, and signing in is a one-time step. Rindler opens a single-use link (it expires in 15 minutes) to the portal's own login page in a browser it manages, you sign in there yourself including any verification code, then click "I'm logged in." Rindler keeps the session that follows, encrypted with AES-256-GCM under a key scoped to your account, and reuses it on later runs until it expires. Some portals tie a login to one live browser window, and there you sign in per task. Storing sign-in details is the exception, not the default. It runs on a limited set of sites we enable one at a time, you opt in per site, and it is encrypted the same way.

Yes, on the sites where Rindler holds the login. One person on your team saves it once, and the whole team's runs sign in with it, including while that person is away. Nobody reads the password back out afterwards, not our staff and not the person who saved it. On most portals there is no stored password at all, because the sign-in happens on the real site and Rindler keeps only the session that follows. Where a login is saved, Rindler holds one per site, and saving another replaces the one that was there. So agree who holds it before you set it up, and if two people on your team work the same portal under different accounts, tell us which portals those are so we can set them up separately.

No. Rindler does not receive or store payment-card numbers. Stripe collects and processes card details and billing contact data for Rindler subscriptions. Rindler stores only the payer email and the identifiers, amount, currency, and status needed to reconcile a bill. Rindler does not enter payment details on the portals it works in.

Yes, Rindler sends your instructions and what it read on the screen to Anthropic (Claude), and to OpenAI when you select it, and it opts out of training and of default retention. Anthropic's default API tier does not train on inputs, and OpenAI requests are sent with retention switched off. Your name, email, and account id are never sent to either provider as request metadata.

Rindler's published sub-processors are Clerk, Anthropic, OpenAI, Amazon Web Services (AWS), Porter, Sentry, PostHog, Cloudflare, Kernel, Browserbase, BrightData, Capsolver, Anti-Captcha, Resend, Stripe, Slack, and Infisical. Rindler does not sell or share your personal information with advertisers or data brokers, and it uses no ad trackers, fingerprinting, or session-replay. See Rindler's published privacy policy or email [email protected] for the full list.

Yes, Rindler lets you delete your data. Rindler honors access, correction, and deletion requests within 30 days, and you can revoke any saved sign-in, which deletes the encrypted session record. GDPR and CCPA rights are honored, and you can set chat history to auto-delete after 7, 30, or 90 days. Email [email protected] to exercise these rights.

We are not SOC 2, HIPAA, or PCI certified. We do not claim certifications we have not earned. Send us your questionnaire and we will fill it in, and we will get your security team on a call with us. Reach us at [email protected].

Yes to both, signed before you name a portal or set up a login. Send us your NDA and we will sign it. Send your data protection agreement and we will get it signed. On those two we work off your paper, and your reviewer starts today on what is already published. Our terms say you keep ownership of everything you send us. We do not use your content to train models. The privacy policy names the outside services that process your data, and we honor a deletion request within 30 days. Send the paperwork to [email protected], the same address a security questionnaire goes to.

Yes. Rindler acts on sites your team already has access to, signing in with your own account when a site requires it, the same way your team would in its own browser. It only reaches what your team could reach itself. You are responsible for using it in line with the terms of the sites you access, the same as when your team uses them directly. The work runs at your direction, on your own account, and if the office or the vendor objects we stop that site immediately.

It runs on your own account, at your direction, the same way your team signs in. If the site objects, we stop that site immediately. If a site still acts against an account, that sits with you, and our Terms say so in plain words. What I commit to is doing the work carefully and stopping the moment anyone on their side asks us to. If you want the exact wording, it is the third-party section of our Terms.

On most sites you complete 2FA yourself once, in a browser Rindler manages, and Rindler never sees the codes. It opens a single-use link (it expires in 15 minutes) to the real login page, where you sign in and finish whatever verification the site asks for. After you click "I'm logged in," Rindler keeps only the resulting session, scoped to that one site. Some portals demand a fresh one-time code every time; there Rindler collects the code for that one task and never saves it.

On most sites, no. You sign in once and Rindler reuses that session later instead of asking again. Some portals tie a login to a single live browser window, and there you sign in per task. The session is stored encrypted with AES-256-GCM under a key scoped to your account and replayed on later runs. Sessions do not last forever: when one stops working, the run stops and asks you to sign in again through the same one-time link, rather than carrying on and handing back nothing. You can also revoke any saved login yourself, which deletes the encrypted record.

As long as the portal itself keeps you signed in. Every site sets its own clock, and Rindler keeps using your session for as long as that site's sign-in holds. Some sites hold a session for a long stretch and others drop it quickly. You can see where each site stands, whether the sign-in is still good and the day it was made, and end one yourself whenever you want. If a session runs out during a task, the run stops and says the sign-in expired rather than handing back nothing, and reconnecting is the same one-time sign-in you did the first time. A portal that ties a login to one live browser window is a temporary session and ends on its own.

Rindler acts only on sites your team already has access to, signing in with your own account the same way your team would in its own browser. It reaches only what your team could reach itself, and it does not create accounts or get around access you do not have. You are responsible for using it in line with the terms of the sites you access, the same as when your team uses them directly. Stripe separately processes Rindler subscription billing.

Yes. A task signs in, pulls the file down and hands back a direct download link that needs no login and expires in about 30 minutes. Statements, transaction exports, CSVs and PDFs all come back the same way. On a run you kick off, the file comes back with the records from that run, so nobody signs back in to go and get it. On a schedule it is worth knowing the link is short-lived, so tell us where the files have to end up and we will tell you what we can do about it before you start. A capture that did not work comes back saying so, with the step named, instead of reporting success and leaving somebody to hunt in a downloads folder for a file that is not there.

Nothing. Rindler runs in your browser at chat.rindler.ai. There is no software to put on anyone's machine and nothing for IT to host. You sign in, describe the task, and it runs on Rindler's side. The portal logins stay with your team: you complete the first sign-in yourself, and Rindler holds only the encrypted session that follows.

You describe the task, Rindler opens the site, signs in with the session you set up, works through the steps, and hands back the result as rows plus any files it collected. The first run on a new site is where the work is: Rindler goes through the screens once and builds the job. After that the same task repeats without rediscovering the site. If it hits something it cannot get past, it stops and says what stopped it instead of handing back a half-finished answer.

Only if your own policies say so. There is nothing to deploy, no server to run, and no change to the portals themselves. The conversation IT usually wants is about accounts and access: which login Rindler uses, what that login can reach, and how to switch it off. You can revoke any saved login yourself at any time, which deletes the stored session.

Yes, on the Teams plan. Save a task, put it on a schedule, and the Monday morning pull is done before anyone is at their desk. On Starter you start each run yourself and decide when it goes. A scheduled run keeps its steps and where it stopped, the same way one you kick off does. Nothing is pushed at you, so it is there when you look, and a week that did not run does not look like one that did. If a schedule stops being able to do the job, that escalates to us, and fixing the site is our job rather than yours.

A run you kick off does. A scheduled run today leaves you the run and every step it took, and getting the records out of that is part of what we scope with you. It is worth being exact about this because it decides how you use it. Kick a job off and the records and any file it collected come straight back. On a cadence, what is kept is the run itself: the steps, the screens, and where it stopped if it stopped. Tell us where the records need to end up and we will tell you what we can do about it before you start.

Yes, as a schedule with a rule attached: a number you set, above this, below that, or how many rows match. Each run measures the fields you named against that number, not against what the page said last week. Nothing is pushed at you, so the answer is there on the run when you look. Save the task once and run it as often as every five minutes. It looks at those fields rather than the whole page. A run that could not finish comes back saying so, with the portal and the step named. Where the answer needs to land after that is part of what we scope with you. Saved tasks and their schedules are on the Teams plan.

As much as your team actually runs. A few hundred items works through in one pass, and heavier bursts are part of an Enterprise agreement. Send a batch as one job rather than splitting it up by hand. For work that runs daily or weekly, the number that matters is whether Tuesday's run landed, not how many ran at once, and every run keeps its steps so you can see that it went through. When the site changes and a job stops, fixing it is our job, centrally, once, for everyone on that site. You do not file a ticket and you do not pay for the repair.

Send us the address. We go through it and tell you what we find: a straightforward site is a small job, and a login-walled portal with several screens is more. For a portal behind a login we ask one person on your team to do the first sign-in. After that the task is yours to run whenever you want. Nothing about the portal itself changes, and the vendor does not need to be involved.

Each site has its own automation with its own cadence, and every run keeps the steps it took and the screens it saw. You open a run and walk it: each step, in order, with what it did. The screens it moved through are listed in the order it hit them, and the run itself downloads as a CSV or JSON file you can attach to a ticket. The automation itself carries when it last ran and when it runs next. Where the data sits, how long it is kept, and what a saved login can reach are on the security page. Nothing is pushed at you, so the run is there when you look, and a run that could not finish comes back saying so with the portal and the step named.

The sites you log into. What runs today includes applicant tracking boards, bank sites, state business registries, and a public catalog you can browse inside the app. Carrier, payer, supplier and client VMS portals are set up per customer, which is most of what teams bring us. Send us an address and we set that one up. We do not publish a count of covered sites, because the only number that matters to you is whether yours is one of them.

Yes. Paste the address at chat.rindler.ai and Rindler works out the site's screens for you, with a quick pass or a deeper one. The result is private to your account, and it is tested against the real site before you rely on it. If the site is behind a login, you do the one sign-in and then it is ready to use.

Every run ends with a clear answer: it completed, or it says plainly that it did not and what stopped it. Every run comes back with the portal's own confirmation: the document number, the rows it pulled, the status it read. A run that could not finish comes back saying so, with the portal and the step named.

Never a made-up one. A value only comes back if it was read off the page. When a field we agreed on is not there, what comes back names that field instead of leaving a silent blank. The fields that were on the page still come back, so a thin record is not a lost one. If the missing one is the thing you asked for, you get told it was unavailable rather than an answer put together from the rest. Whole lists work the same way. An empty result counts as an answer only when the site itself says the list is empty, and rows we could not read come back saying so, with the screen named.

Yes. An ordinary redesign is not an outage, and when a change is big enough to stop a task, fixing it is our job. Rindler works from what a screen means rather than the exact position of a button. A change big enough to stop a task comes back as an exception on that run. This is included on every plan.

Yes. Portals that expect a person in a browser, and offer no other way in, are the normal case for this work. Rindler works the way your team does: signed in with your own account, on the real screens, which is why it reaches pages that a canned report export never shows. If a sign-in step needs something extra, you clear it yourself during the one-time sign-in, and that is the last time it asks.

No. Rindler drives a real browser and waits for the screen to finish, the same as a person would. Slow portals, pop-ups, session warnings, and screens that assemble themselves a piece at a time are ordinary here. What comes back is the same shape of result every run, so whatever you feed it into does not have to change when the portal does.

Yes. Point it at a document and it hands back the text page by page, with the page numbers, so a long remittance advice or policy document can be searched instead of read. For long files you can ask for only the pages containing a phrase, or a page range like "1-3,7". There are two different jobs here and it is worth separating them: collecting a document from inside your own session on a portal you sign in to is part of what we build for that portal, and reading the text out of a file that sits behind a login is not covered yet. A scanned page with no text layer comes back saying there is no text on it, rather than coming back empty.

Paste the address and we set it up. Rindler names the site it does not have yet, so you know exactly which one to send us. You get the address itself (<domain>) rather than a vague error. You can also add most sites yourself by pasting the address at chat.rindler.ai. A one-off timeout is a different thing and is simply retried.

Sign-in, navigation, retries, and recovery are handled for you, so most hiccups never reach you. What does reach you is said plainly: this run did not complete, and here is where it stopped. A pop-up that blocks the page gets cleared and the step retried, rather than losing the progress before it. An expired login asks you to sign in again. A portal that is down is reported as a portal that is down. Nothing is reported as done that was not done.

Yes. What it learns about a site carries from one run to the next: the quirks, the order the screens want things in, the way your team names things. That is why the first pass through a new site is the work and the runs after it are not. What it remembers is scoped to your account and is never returned to another customer.

Live, every run. Rindler opens the portal, signs in, and reads the records straight off the screen, so what comes back is what the site was showing at the time. No records are carried over from an earlier run. What carries over between runs is the layout: the screens a site has, and the route to each one. Before Rindler uses a stored route, it checks that the screen in front of it is the one it recorded. The stored layout never stands in for the live one. Files work the same way. A statement or an export is collected from the portal during the run, not a copy we kept from last time.

Rindler reads the filters off the screen each time rather than assuming a fixed set. That matters on portals where choosing a line of business or a plan year changes which fields appear at all. Rindler applies whatever the portal is offering right now, so a field the vendor added last night does not break the task.

Both. It searches, filters, downloads, fills forms, uploads attachments, and works through multi-step submissions, using the same sign-in as the reads. The boundary is deliberate: nothing is submitted, paid, or changed unless you asked for it. Anything that files or spends comes back with the confirmation the portal issued, so you have proof it went through. Stripe separately processes Rindler subscription billing.

We go through it once, screen by screen, and build the job. That first pass is the work. After that the same job repeats without anybody rediscovering the site. That is why the list of sites matters more than the volume: taking on a new one is a piece of work and running it again is not. If the site is behind a login, one person on your team does the first sign-in. On most portals that is the only time; some tie a login to one live browser window, and there you sign in per task.

The rules that decide what to skip are part of what we scope with you before the first run. On a records job the useful rule is usually a skip: when a case shows a stipulation of settlement, there is no reason to pull the individual documents. Tell us the rule the way you would tell somebody new, and we agree it with you before the job runs for the first time.

It counts as a site behind a login, because the account is the thing that does the work. On public-records portals the free search usually gives you the list, and the records themselves sit behind an account the office grants to a named person. You register and you hold that account. We work inside it, we never create one, and we reach only what your own account reaches.

The work is what differs, and a site behind a login with documents to collect is the most work there is. One person on your team signs in once. The session has to be held, and re-established when the portal drops it, and the documents have to be collected inside it. A public site we have already been through repeats cheaply, so volume on public sites is not the part that costs. The one piece of real work is the first pass through a site we have not seen. Send us the list and we will tell you which of yours is which.

Rindler publishes two prices: Starter at $100 a month, which begins with a 7-day free trial, and Teams at $1,000 a month. Enterprise agreements are quoted directly rather than listed. Starter, for a team running one portal by hand today, starts with a 7-day free trial and includes the sites already in the catalog, one login-gated site of your own set up with you, and 100 one-off runs a month. Teams raises that to ten login-gated sites of your own, 1,000 runs a month, and saved tasks you can put on a schedule. A run is one completed task, and it is $1 whether you are on Starter or on Teams. There is no volume discount one rung up. Enterprise, for teams running this work at scale, is an annual agreement billed monthly that adds more portals and headroom above the runs included.

Yes. Enterprise is an annual agreement, billed monthly, quoted directly rather than listed, for teams running this work at scale. It adds more sites of your own, public and login-gated, set up with you, headroom above the runs included in the agreement, and dedicated onboarding, and the first month runs as a pilot with an exit clause. What we commit to is a number of portals kept working to a defined bar, not an uptime percentage. Contact [email protected] or schedule a call from rindler.ai/pricing to discuss.

Try it at chat.rindler.ai with no account: describe one task your team does by hand today and watch it run. Buying is a different door. You start Starter's 7-day free trial at rindler.ai/pricing, and your dashboard is at app.rindler.ai. Use your work email at checkout, so your payment can be matched to your workspace. If you do not have one yet, you set it up next. Pick the task your team complains about most rather than the easiest one, and judge us on what comes back on the day the portal misbehaves. If you already know the sites, send the list and what has to happen on each one, and we come back with what we take on. Two things from you: one person to do the first sign-in on anything behind a login in the first week, and somebody who can answer scope questions inside two days.

Rindler was founded in 2025 by Michael Serrano and Arthur De Los Santos, who met at MIT in 2022 and did research at MIT CSAIL. Rindler is backed by Y Combinator and automates the web work teams still do by hand, on the portals that have no API and never will. You can reach the founders directly at [email protected].

Neither per click nor per site. You pay for completed runs, with no per-step and no per-site fee. Starter starts with a 7-day free trial and includes the sites already in the catalog, one login-gated site of your own set up with you, and 100 one-off runs a month. Teams raises that to ten login-gated sites of your own and 1,000 runs a month, at the same rate per run, so there is no volume discount one rung up. Enterprise is quoted directly and adds more portals and headroom above the runs included. A run that does not complete is not a run you pay for.