Table of contents
Most title API integrations pass their own test suite. They pass because the suite was written against the sample payload in the documentation, and the sample payload is a suburban parcel in a fully digitized county with one owner, one lien and a legal description that fits on a line.
The thing you are integrating with is not a service. It is several thousand recording jurisdictions behind one endpoint, and the variance those jurisdictions produce is the part your test plan usually misses. A pipeline that handles the sample payload beautifully can still stall on a Texas metes and bounds description, a multi-parcel agricultural tract, or a county that returns an index entry with no image attached.
The fix is not more testing. It is testing the two different things that can break, because they fail in completely different ways and you cannot catch the second kind by exercising the first.
What you are actually integrating with
One endpoint in front of many filing offices
Property records in the United States are held at the county or equivalent level, and every one of those offices makes its own choices about what goes online, how far back the images run, how names are indexed, and what a search result even looks like. A good vendor API hides that behind one contract. It cannot make the underlying variance stop existing.
So the same well-formed request can come back in minutes from one county and take a human visit in the next. That is not an error condition, and an integration that treats a longer turnaround as a failure will spend its first month paging an on-call engineer about counties working exactly as expected. The background on that variance is covered in why title work turn times vary.
Two categories of failure
Transport failures are the ordinary distributed systems problems. Timeouts, retries, duplicate deliveries, expired credentials, rate limits, a webhook endpoint that was down for eleven minutes. They are well understood and they are testable in a lab.
Domain failures are specific to this data. A vesting string with three owners and two different spellings of one surname. A report where a field is absent because the county does not publish it, which is not the same thing as a field that came back empty. A parcel that splits into two parcel numbers mid-year. These never appear in a synthetic fixture, because nobody thinks to write one.
Seven checks to run before go live
1. Authentication, rotation and least privilege
Prove that credentials can be rotated without downtime, that an expired key produces a clear failure rather than a silent empty result, and that the credential your integration holds can do exactly what it needs to and nothing else. Rotation is the one that gets skipped, and it is the one that eventually happens at an inconvenient hour.
2. Idempotency on order submission
Submit the same order twice, deliberately, with the same idempotency key. You should get one order. Then submit it again after a simulated network timeout, which is the real world version of the same test. Duplicate orders are the most common and most embarrassing integration defect, because the failure is invisible until an invoice arrives.
3. Webhook signature verification
Verify the signature on every inbound delivery and reject anything that does not carry a valid one. Then test the negative cases properly. Send an unsigned payload, a payload signed with an old secret, and a valid payload replayed outside the timestamp window. All three should be refused and logged. The mechanics of the delivery model are covered in the webhook overview.
4. Duplicate and out-of-order delivery
Webhook delivery is at least once, not exactly once. Your handler will eventually receive the same event twice and will occasionally receive a later event before an earlier one. Test both by replaying deliveries out of sequence. The handler should be safe to run repeatedly and should decide state from the event content rather than from arrival order.
5. The error taxonomy, exercised deliberately
Force each failure class and confirm the behavior, rather than hoping the generic catch block is adequate.
| What happens | What the integration should do |
|---|---|
| Rate limit response | Back off with jitter and resume, never drop the order |
| Server-side error | Retry with escalating delay, then surface to a queue a person watches |
| Request timeout | Retry using the same idempotency key so no duplicate order is created |
| Validation rejection | Fail fast, show the operator which field was wrong, do not retry |
| Order accepted and still working | Keep waiting, this is normal for a county that requires a courthouse visit |
The last row matters more than the others. A pending order in a slow county is a correct outcome, and an integration that alerts on it will teach your operations team to ignore alerts.
6. County variance, not the happy-path fixture
Run live test orders across a deliberately awkward sample. A rural county with limited online coverage. A jurisdiction that records by town or parish rather than by county. A commercial parcel with a long legal description. A property with a recent split or merger. A common surname in a large metro. If every test order came back in under an hour, you have not tested the system yet.
7. Field mapping proven inside the receiving system
Not in a sample payload, not in a unit test. Push a real response through to the actual fields in the LOS and look at the record afterward. This is where integrations quietly break, and the failure mode is described in detail in how poor data mapping creates silent LOS errors.
Data checks that outrank the wire protocol
Absent and empty are different facts
A field that is missing because the county does not publish that item means something very different from a field that came back with no value. Collapsing the two into a null is how a report that said nothing gets recorded as a report that said no. Decide the distinction explicitly and test it, because JSON title report data can express both and your mapping layer has to preserve the difference.
Dates, parties and identifiers
Recording dates, instrument dates and effective dates are three different things and are routinely confused. Party names arrive with suffixes, initials, business entity forms and married names attached. Parcel identifiers are formatted differently in almost every jurisdiction, which is the entire reason Placekey support exists as a stable anchor. Test all three against real records rather than idealized ones.
Additive schema changes should not break you
Your parser should tolerate a new field appearing without failing, and your validation should not assume a fixed set of keys. Vendors add fields. An integration that treats an unexpected key as an error is an integration that breaks on a Tuesday for no reason visible to anyone.
Exceptions are a list, not a flag
A report can carry several exceptions at once, and the count is not bounded. Anything that reads only the first one, or that flattens the list into a single status, is discarding the information the order was placed to obtain.
The parallel run
The last step before cutover is the one worth protecting from schedule pressure. Run the new integration alongside whatever you do today, on the same orders, and compare the outputs rather than assuming they agree.
- Order both ways for a fixed sample. Enough loans to cover several states and a mix of county types, not a handful from one market.
- Diff the results field by field. Every disagreement is either a bug in the mapping or a genuine difference worth understanding before it reaches an underwriter.
- Have somebody who knows title work read a sample. An engineer can confirm the data arrived. Only an abstractor or a senior underwriter can confirm the data is right.
- Watch the operational metrics too. Turnaround by county, exception rate, and the share of orders needing manual follow-up tell you what your steady state will actually look like.
- Write down the rollback. A cutover you cannot reverse in an afternoon is not a cutover, it is a commitment.
Teams that skip the parallel run usually discover the same thing two weeks later, in production, with a closing waiting on it. The broader picture of what these integrations are for is laid out in use cases for lenders, and the connection points themselves in API integrations.
FAQs
What is the most common cause of a failed title API go live?
Field mapping that was validated in a sample payload rather than in the receiving system. The transport works, the data arrives, and it lands in the wrong place or silently overwrites a populated field.
How long should a parallel run last before cutover?
Long enough to cover real county variance rather than a fixed number of days. A pipeline that has only seen large metropolitan counties has not yet been tested, whatever the calendar says.
Why AFX Research builds for the awkward counties
Any vendor can return a clean response for a parcel in a fully digitized metro. The integration question that matters is what happens for the counties that are not, because those are the ones that will decide your exception rate and your worst-case turnaround.
AFX runs a hybrid model behind a single interface. Automated retrieval and normalization where the county data supports it, and a certified human abstractor in the courthouse where it does not, delivered through the same same-day title update contract so your platform never has to know which path produced the answer. That is what makes a test plan meaningful, because the shape of the response does not change when the underlying county does.
Test the transport in the lab, test the variance against real counties, then run both pipelines side by side until the diff stops surprising you.