1. Page 1 of 9
How Houwzer Speeds Growth and
Innovation by Gaining Insights
Into API Use and Behavior
Transcript of a discussion on how a cloud-based home-brokerage-enabler, Houwzer, constructed a
resilient API-based platform as the heart of its services integration engine.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Traceable AI.
Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’re
listening to BriefingsDirect.
Complexity and security challenges can hobble the growth of financial transactions for private-
data-laden, consumer-facing software-as-a-service (SaaS) applications. Add to that the need to
deliver user experiences that are simple, intuitive, and personalized -- and you have a thorny
thicket of software development challenges.
Stay with us now as we explore how streamlined and cost-efficient home-brokerage-enabler
Houwzer constructed a resilient application programming interface (API)-based platform as the
heart of its services integration engine for buying and selling real estate online.
To learn how Houwzer makes the most of APIs and
protects its user data while preventing vulnerabilities,
please welcome Greg Phillips, Chief Technology
Officer (CTO) at Houwzer. Welcome, Greg.
Greg Phillips: Thanks, Dana. It’s nice to be here.
Gardner: Greg, what does Houwzer do, and why is
an API-intensive architecture core to your platform?
Phillips: We are more than just a real estate
brokerage. We’re also a mortgage brokerage and a
title agency. The secret sauce for that is our
technology platform, which binds those services
together and creates a seamless, end-to-end
experience for our consumers, whether they are
buying or selling a home.
Those services are typically fragmented among different companies, which can lead to an often-
chaotic transaction. We streamline all of that into a much smoother experience with our salaried
agents and a consistent technology platform across the whole transaction. We are rethinking
how real estate transactions are done by making it a better experience across the board,
inclusive of all those services.
Early on, we decided to build, essentially, a protocol for conducting real estate transactions.
There are laws and regulations for how to conduct such transactions in different jurisdictions.
Phillips

2. Page 2 of 9
Instead of having an unmanageable variety of local rules and regulations -- in one area they’re
doing it one way, and in another area doing it another way – we looked for the common
elements for doing real estate transactions, mortgages, and for titles.
We’ve built into our system these common elements around real estate transactions. From
there, we can localize to the local jurisdictions to provide the end services. But we still have a
consistent experience across the country in terms of offering services.
That’s why we began with an API-first architecture. We focused on the protocols and building-
blocks of the platform that we offered to our agents, coordinators, and mortgage advisers for
their services. Then we layered on the front end, which has a lot more localization and other
services. So, we very intentionally thought about it as a protocol for conducting real estate
transactions, rather than building an app to manage just specific types of real estate
transactions in specific jurisdictions.
Gardner: When say API-first, what do you mean? Was that how you constructed your internal
platform? How you deliver the services? Was it also for the third-party and internal integration
points? All of the above?
Real estate transactions gain flexibility with APIs
Phillips: All of the above, yes. We wanted to build an API core that was flexible enough to
support lots of variants within different types of real estate transactions. We’re already in seven
states. And we’re still pretty early in our journey. We’re going to be adding more states and
jurisdictions.
So, we knew from the get-go that was our direction. We put a lot of thought into our data model
and our API platform, such that we wouldn’t have to rewrite or break up the APIs every time we
entered a new jurisdiction. We wanted a flexible underlying API that we could use to offer a
finished product, even though it might look a bit different in Maryland than it does in
Pennsylvania, for example.
Gardner: It’s evident that such flexibility, speed of development, and reuse of services are
some of the good things about APIs. But are there any downsides? What can detract from that
versatility when going API-first?
Learn More
About Traceable AI.
Phillips: One of the downsides of APIs is once you put it out there into the world, you are
supporting that API, for better or worse. Things get built against it. And if you want to change or
rethink what you do with that API, you have downstream dependencies reliant on that API.
It’s not like you’re a single code base, where if you want to refactor, you can use your idea to go
discover all the things that might break if you change things. With the API model, it’s harder to
know exactly who’s out there using it, or what might break if you change the API.

3. Page 3 of 9
That means there’s a semi-permanence to an API. That’s somewhat unique in the software
development realm where things typically move with a lot of flux. We have libraries that are
updating all the time, especially in the JavaScript ecosystem. Things are going a mile a minute.
When you deliver an open API, you have to
be more thoughtful about what you put out
there ahead of time, because it is harder to
change, harder to version, and harder to
migrate. It’s by definition something you’ve
chosen to set in stone, at least for some
period of time, so people can build against it.
Our API interacts with third parties. The vast majority of the usage of our API is for our internal
front-end application. It’s not like we have tons of different stakeholders on the API. But we need
to factor for those third parties and partners.
Obviously, then, security is another huge undertaking when you put an API out there. This is not
an API that is just sitting behind a firewall. This is an API on the Internet for conducting real
estate transactions, which are highly sensitive transactions. So, obviously, security is a huge
concern when building an API.
Gardner: With so many different parties involved in real estate transactions, to get people to
rely on Houwzer as a hub, there needs to be an element of trust. Not just trust about
performance, but trust that the activity is going to be safe, and privacy is assured.
What did you do to bring that level of resiliency to your API? How did you troubleshoot your own
API to make sure that others would view it favorably?
Keep data safe from start to finish
Phillips: From the very beginning, we’ve been really concerned with security. Even before we
had any transactions running through the system -- and we were just in the design phases of
the API -- we knew we’re in an industry that’s constantly under attack.
The most common and dangerous thing that happens in the real estate brokerage industry is
when some non-public information about a transaction is somehow leaked. There are a lot of
criminals out there who can use that information to attempt to exploit our customers. For
example, if they find out information about when a closing is supposed to be in the name of the
title company, they could pose as an agent of that title company and say, “Hey, for your
upcoming closing, the wiring instructions have changed. You actually need to wire ‘here’ instead
of ‘there’.”
We’ve seen brokerages across the country fall victim to that consistently over the past five to 10
years, if not longer. It’s been a huge problem in the industry. So, while an API enables a great
user experience by having very streamlined transactions, we need to make sure that the
information stays private to only our clients, agents, and coordinators -- and not leak any of that
data to the public through the API. That’s been paramount for us.
When you deliver an open API, you
have to be more thoughtful about what
you put out there ahead of time,
because it is harder to change, harder
to version, and harder to migrate.

4. Page 4 of 9
As far as performance goes, we’ve been fortunate that our business has relatively few high-
value transactions. We haven’t had to achieve super-scale yet with our APIs. Our security
concerns are a 10, but our scalability concerns, fortunately, are at a two. So far, it’s not open to
the masses. It’s more of a premium service for a smaller audience than a free service on the
Internet.
Gardner: Given the need for that high level of security, you can’t depend on just the perimeter
security tools. You need to look at different ways of anticipating vulnerabilities to head them off.
Phillips: Yes. You must be aware of what
you’re putting out into the world. You must
assume the worst about who is going to interact
with your API, and make sure there is no way
for an unauthorized person to gain access to
information they’re not privy to.
Since the beginning of building this platform, that kept me up at night. One of the things that
ultimately led me to Traceable AI was that I wanted to effectively gain more confidence about
how my APIs were being used out in the world. You try to anticipate as much as you can when
you’re building it.
Learn More
About Traceable AI.
You reason: “Okay, who’s going to be calling on this? We don’t want to expose any additional
information here. We want to have just the information needed, with no additional information
that might leak out. We want really strong access controls on each API request, such as what
parameters will be accepted, what will be updated, and what will show in each scenario based
on all the different users’ rules.”
Obviously, that’s a lot to keep track of. And you always worry there is some misalignment or
misconfiguration that you’re missing somewhere. You want to be able to monitor how the API is
getting used -- and, essentially, have an artificial intelligence (AI) capability look for that type of
thing in addition to your ability to query for it.
That has been very attractive for us. It’s given us a lot of confidence that, in practice, we are not
leaking data. It’s an additional level of validation. Instead of enforcing a perimeter and not letting
anybody in, we’re very careful about what we put out there beyond the perimeter. And not only
are we careful about what we put out there beyond the perimeter, we’re also monitoring it very
closely, which I think is key.
Monitor who’s doing what, where, and when
Gardner: Such monitoring gives you the opportunity to create a baseline of behaviors, so that
even for unintended consequences of how people use your API, you have a data record. And
you’re doing it at scale because there’s a lot of data involved that humans couldn’t keep up with.
Instead, you have machine learning (ML) and AI technologies to bring to bear on that.
What have you learned from that capability to observe and trace to such a high degree?
You must assume the worst about
who is going to interact with your API,
and make sure there is no way for an
unauthorized person to gain access
to information they’re not privy to.

5. Page 5 of 9
Phillips: We have discovered a few vulnerabilities that we weren’t aware of. So, there were
areas where we were exposing, or potentially exposing, more information than we meant to
through a given API endpoint. That was identified and fixed.
We’ve also seen some areas where people have tried to attack us. Even though we don’t have
the vulnerability, we’ve seen malicious actors hitting our API, attempting to do a sequel injection,
for example, or attempting to read a file on the file system, or to run a command down the
system. You can actually see that stuff and observe how they’re doing it without having to parse
through raw API requests, which aren’t humanly readable. Those are the first order of insights
we’ve gained.
The second order of things we’ve seen are also very
interesting. We can look at the API requests
segmented by our users and our user roles. That
means learning what API requests our clients,
agents, and coordinators tend to make. We can now
examine how these different stakeholders interact
with the API. It has been really interesting to see from
a planning perspective.
Even outside of security, it’s been fascinating to see how the system gets used, and the kinds of
natural rhythms that occur, such as when is it used during the day. What are these types of
things happening versus these other types of things happening?
It’s interesting to see that which would be very hard in the non-human-readable API requests.
When you aggregate it and display it in an information display, you can see that stuff. The API is
a living, breathing thing that you can look at and observe as it’s out there in the world.
Gardner: Not only as it breathes and lives, but it’s easily updated. So how do you create a
feedback loop from what you learn in your observability phase and bring that into the
development iteration process?
As the CTO, are you the one that has to cross the chasm between what you can observe in
operations and what you can subsequently ameliorate in development?
Security now part of everyone’s job description
Phillips: Generally, yes. I view that as a key part of my role. Our software engineers are in
there looking at it as well, but I hold myself accountable for that function. Also, I try to recruit
generalist software engineers who can take security into account, just like with user experience,
when they’re building things.
I find it very hard to build a cohesive and secure product if you are just throwing requirements
over the fence to the software engineers from different departments, saying, “Build this.” I think
you lose something.
Rather, there has to be a complete understanding in one accountable individual’s mind to
deliver the complete product. And that’s not to say those areas of the company shouldn’t have
We can look at the API requests
segmented by our users and our
user roles … and learn what API
requests our clients, agents, and
coordinators tend to make.

6. Page 6 of 9
input on what gets built. But the engineers in my mind have to have a deeper understanding. I
like to give them as much data as possible to understand what they’re putting out. Then they
have that all in their minds when they’re writing the code.
Gardner: Have your developers been receptive to this observability of API behavior data, or do
they say, “Well, that’s the security person’s job, not mine”?
Learn More
About Traceable AI.
Phillips: All of us on the team feel a responsibility for the security of our systems. I think
everyone takes that really seriously. I don’t think anyone thinks that it’s “someone else’s”
problem. We all know that we all have to watch out for it.
That being said, not everyone is a security expert. Some people may know more or less than
others about information security. None of us are dedicated information security professionals.
We rely on the inputs from the Traceable AI platform and from what we’re seeing happen to
learn about the things that we should be worried about. What are the things that we don’t even
know about yet?
It’s about having a culture of learning and having
generalists who want to get better at building secure
systems and to convey secure APIs. That is
increasingly part of the job description for software
engineers, to take that into account. That’s
especially critical as we see higher value services,
like our own, being offered directly on the Internet.
Things are so different now. Years ago, real estate and other financial transactions had some
kind of application front end. Then some person would put it all into a mainframe that night and
do the financial transactions. Then, the next morning, after it ran on the mainframe, the humans
would look at it again. And then they would update your bank account.
Now there’s far more automation. Things happen live via APIs on the Internet. And that’s
created much more reason for developers to truly understand the security implications of what
they’re building. You simply can’t insert a failsafe as easily, as you start to eliminate process
friction, which is what consumers want. There are less natural insertion points for a true
dedicated security or dedicated fraud prevention review. You have to do these processes live
and in an automated way. Security therefore has to be built into the thing itself.
Gardner: Of course, these transactions come with high urgency for people. This is their home,
one of the biggest transactions of their lives. They’re not interested in a wishy-washy API.
How easy was using Traceable AI to bring automation for better security into your organization?
Sliced and diced data delivers better development
Phillips: What I like about the Traceable AI user experience is that you can engage with it at
multiple levels. On the most basic level, you log in and it’s pushing out immediate alerts of
It’s about having a culture of
learning and having generalists
who want to get better at
building secure systems and to
convey secure APIs

7. Page 7 of 9
threats. You can view what has happened since you last logged in, and you can review your
bots. It surfaces the most important things right away, which is great.
But then you can also pursue questions about the APIs in production. For example, you can plot
how the APIs are being used. They give you great tools to drill down so you can navigate to
different ways of aggregating the API usage data and then visualize, as I mentioned before,
those usage patterns.
You can look at performance as well as security. So even if you’re feeling good about the
security, you can determine if latency doesn’t look great, for example. There are a lot of things
in there to show where you can go really deep. I don’t think I’ve gotten to the bottom. There’s
more to discover, and there’s tons of ways to slice, dice, and look at things. I tend to do that a
lot because I’m a power user and like to figure things out. But at the same time, Traceable AI
does a great job of using their intelligence to surface the most important things and the most
critical security concerns and get those in front of you in the first place.
Gardner: It sounds like these data deliverables provide you an on-ramp to a more analytics-
driven approach to not only development -- but for improving the processes around
development, too.
Phillips: Yes. I would even extend that into the
processes around our business operations, our
real estate operations. We’re offering a product
through our technology that is ultimately a real
estate transaction engine. And we can actually
see in the API things that we need to do to make
the real-world solution better.
We have three critical stakeholders: the buyer client, the real estate agent, and the transaction
coordinator, who makes sure everything goes smoothly. And, using these tools, we can see if
the user or coordinator are trying to do something, meaning they’re getting errors. We can see if
there is a point in the real estate transaction where we might not have everything included.
Maybe the information that was expected to be there is incomplete, and so they are not able to
get to the next step of the transaction.
So, you can actually uncover things that are not explicitly in the technology, like a process
problem. We need this information ahead of that point in the process, and we don’t always have
it. We want to then know what next to build into our protocols for the future.
Gardner: Greg, what are your suggestions for other folks grappling with the API Economy, as
some people call it? Any words of wisdom now that you’ve been through an API development
and refinement journey?
Happy homeowners take one real estate step at a time
Phillips: Start small and expand. Don’t try to put everything and the kitchen sink out there all at
once. We currently represent people selling their home, buying a home, and getting a mortgage,
people who need title insurance -- people doing all of those things together all at once.
We’re offering a product ... that is
ultimately a real estate transaction
engine. And we can actually see in
the API things that we need to do to
make the real-world solution better.

8. Page 8 of 9
However, the first transaction through our system was just people listing their homes. We said,
“Let’s take on this specific process.” And even at the time that we launched, it was a much less
detailed version of the process we have today. It’s really important to release something early
that is complete but limited in scope. Scope creep -- of trying to pack in a lot at once -- is what
causes security issues. It’s what causes performance issues. It causes usability issues. So, start
simple and expand. It’s probably the best piece of advice I have.
Gardner: Assuming you are going to continue to crawl, walk, and run, what comes next for
Houwzer? What does the future portend? What other transactions might this protocol approach
lend itself to?
Learn More
About Traceable AI.
Phillips: We thought about all the things needed to consummate a real estate transaction. We
have covered three of those. But we are missing one, which is homeowners’ insurance. We
consider the core services to purchasing a home as brokerage, mortgage, title, and
homeowners’ insurance. So that piece is in the works for us.
Outside of those core pieces, however, there are lots of things people need when they’re buying
and selling homes. It could be resources to fix up their current home, resources to move in,
guidance around where in the country they should move to as a remote worker. There’s lots of
different services to build out to from the core.
We began at the core transactions, and now we can build our way out. That was a very
intentional strategy. When you look at Zillow, Redfin, or some of the other real estate technology
companies, they began with the portal and then tried to bolt on the services.
We’re trying to build the best technology-enabled real
estate services, and then build from that core outward
into more of those needed services. Some of the next
things in our product road map, for example, are pre-
transaction, helping our consumers make more
educated decisions about the transactions they’re going
to enter into. And we can do that because we have this bullet-proof, secure, battle-tested
system for doing it all and great real estate agents that will help guide you through the process.
Gardner: I’m afraid we’ll have to leave it there. You’ve been listening to a sponsored
BriefingsDirect discussion on how a streamlined and cost-efficient home brokerage enabler,
Houwzer, constructed a resilient core API platform.
And we’ve learned how protecting user data and preventing vulnerabilities across an end-to-end
API services approach has allowed Houwzer to deliver user experiences that are simple,
intuitive, personalized, and trusted. So, a big thank you to our guest, Greg Phillips, Chief
Technology Officer at Houwzer. Thanks so much, Greg.
Phillips: Yes, thank you as well. It’s been a pleasure.
We’re trying to build the best
technology-enabled real
estate services, and then
build from that core outward.

9. Page 9 of 9
Gardner: And a big thank you as well for our audience for joining this BriefingsDirect API
resiliency discussion. I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host
throughout this series of Traceable AI-sponsored BriefingsDirect interviews.
Thanks again for listening. Please pass this along to your business community and do come
back for our next chapter.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Traceable AI.
Transcript of a discussion on how streamlined and cost-efficient home-brokerage-enabler, Houwzer,
constructed a resilient API-based platform as the heart of its services integration engine. Copyright
Interarbor Solutions, LLC, 2005-2021. All rights reserved.
You may also be interested in:
● How FinTech innovator Razorpay uses open-source tracing to manage fast-changing APIs
● Traceable AI platform builds usage knowledge that detects and thwarts API vulnerabilities
● How to migrate your organization to a more security-minded culture
● How API security provides a killer use case for ML and AI
● Securing APIs demands tracing and machine learning that analyze behaviors to head off attacks
● Rise of APIs brings new security threat vector -- and need for novel defenses
● Learn More About the Technologies and Solutions Behind Traceable.ai.
● Three Threat Vectors Addressed by Zero Trust App Sec
● Web Application Security is Not API Security