Ask a title officer, a property manager, or a closing coordinator where a deal actually lives, and the answer is rarely a single system. It's a county recorder's site to pull a deed, an assessor's portal to confirm a parcel's tax status, a title/escrow platform to track a closing, and an MLS compliance form to file a disclosure—each one built years ago for a person at a desk, county by county, with no shared login and no shared schema. Real estate runs on more disconnected, jurisdiction-specific portals than almost any other regulated industry, and that's exactly where a single API integration was never going to cover the workflow.
Property Records Live in Portals, Not APIs
A single transaction can touch a dozen systems that don't talk to each other: a county recorder's office for the deed history, a tax assessor's site for parcel and lien status, a title company's own portal for closing documents, and an MLS system with its own disclosure and compliance forms. Some of these expose a limited, read-only API for public record lookups. Almost none of them expose an endpoint for the parts that actually require a login—pulling a full title chain, checking an escrow status, or submitting a disclosure on behalf of a client. And in real estate specifically, the filed form or the recorded document is the legal record itself, not a JSON response asserting that something happened.
That leaves the browser as the only reliable way in, which means the automation running against a county portal or a title platform has to be held to the same standard as the person who used to do that work by hand—not a scraper that quietly breaks the first time a county updates its site.
One Identity Per Portal, Not One Password in a Script
Every county site and title portal is its own login, and pasting a service account's credentials directly into a script is how they end up in logs and version history. Anchor's identities let a team define each portal's login once and reuse it by reference:
const countyIdentity = await anchorClient.identities.create({
source: 'https://recorder.countyexample.gov',
name: 'Title Ops - County Recorder Portal',
credentials: [{
type: 'username_password',
username: process.env.COUNTY_PORTAL_USER,
password: process.env.COUNTY_PORTAL_PASS,
}],
});
const session = await anchorClient.sessions.create({
identities: [{ id: countyIdentity.id }],
session: {
recording: { active: true },
},
});
// Session opens already authenticated against the recorder's
// portal; the credential itself never passes through the script.The same pattern holds whether the portal on the other end is a county recorder, a title/escrow platform, or an MLS compliance system—one identity per portal, attached to a session instead of hardcoded into automation code.
The Session Is the Record a Compliance Review Wants
Real estate compliance reviews and post-closing audits tend to ask the same question: not "did the job report success," but "what did the portal actually show when that disclosure was filed or that lien search ran." Session recording is on by default and captures the run as video, giving a broker or compliance team an independent record of what happened on screen—useful when a title dispute or a fair-housing review surfaces weeks after the fact and someone needs to see the original run, not just a log line. For higher-stakes filings, Anchor's live view can also be embedded read-only, so a supervising broker or compliance officer can watch a submission happen in real time without being able to take over the session.
Standing Access, Not a Workaround
None of this is about getting around a county site's defenses or a title platform's login screen. It's the same portal access a title team, property manager, or agent already has standing rights to use—run under an identity a security review can trace and a session a compliance audit can replay. If your team is still logging into a rotating list of county, title, or MLS portals by hand for every transaction, that's the gap Anchor is built to close. Get an API key and bring the next recorder search or disclosure filing into the same governed session model the rest of your stack already runs on.
