Inconsistent lookup between UI and both API endpoints

[patienttruth]

Inconsistent lookup w/ address

Address - 18404 Doctor Joe Road
Zip - 98257

On https://webgis.dor.wa.gov/taxratelookup/SalesTax.aspx we get 2909 which is assumed to be correct.

Effective dates7/1/26 - 9/30/26
Location code [(view map)](javascript:ZoomMap(-13640249.3068289,6170001.11075721,'2909','18404 Dr Joe Rd Skagit County 98257 9337');)2909
City
CountySkagit
State Sales and Use Tax.065
Local City/County Sales and Use Tax.018
Total tax rate.083
Confirmation code72F41CE18D

On /AddressRates.aspx we get 2900

<?xml version="1.0" encoding="utf-8"?><response loccode="2900" localrate=".018" rate=".083" code="2" xmlns=""><addressline code="2900" street="SNEE OOSH RD" househigh="18404" houselow="18404" evenodd="O" state="WA" zip="98257" plus4="8900" period="Q32026" rta="N" ptba="" cez="" /><rate name="SKAGIT COUNTY" code="2900" staterate=".065" localrate=".018" /></response>

On /GetTaxRate we get a geocoding error

{
  "type": "Lookup failure",
  "title": "Failed to find address",
  "status": 400,
  "detail": "Failed to geocoded the address provided. Please try another address, or reformat the current address."
}

It seems the WA DOR UI is fixing the address name to Dr which is great. If I try that single change to the address in the API it fixes the lookup on both end points, however I'd have assumed the UI would give the same result as the /AddressRates.aspx end point at least. For whatever reason my CRM auto corrects the address to Doctor Joe Road, so even if I or a client put Dr Joe Rd it would have autocompleted otherwise and broke this. This may be rooted in a CRM issue, but the inconsistent responses are the main point of this issue.

[uncheckederror]

Hi there, thank you for the bug report. Following the steps you provided I am able to reproduce the differing responses on each of these endpoints.

I have added a test that compares the response of the /GetSaleTax endpoint for "18404 Doctor Joe Road" and "18404 Dr Joe Rd" and ensures that they are the same. The API endpoint that this project uses to geocode addresses seems to work better with the abbreviated road names. Thus I've added a function to apply common abbreviations to address if geocoding the initial address doesn't return any results.

I believe this solves the bug you've reported here as the response from the /GetSaleTax endpoint is now identical to the response on the WA DoR's website for the address 18404 Doctor Joe Road 98257.

You can try it for yourself here: https://wataxlookup.acceleratenetworks.com/GetTaxRate?addr=18404+Doctor+Joe+Road&zip=98257

[patienttruth]

Hi.

That looks great, and the logic makes sense to me. "Doctor" needing to be abbrieciated is quite the edge case.

Any thoughts on why /AddressRates.aspx gives a different result? When I made the bug report it was returning 2900. This morning it is returning 2931. Considering it's deprecated, maybe it doesn't matter? I'm gonna guess it's a different geocoding service and it puts the coordinates somewhere else nearby vs /GetTaxRate, but the inconsistency within itself is what stood out.

Are the actual coordinates used able to be exposed on either end point?

I have another thought regarding the /GetTaxRate that I'd be willing to take a look at if you're interested.

Do you see any value in returning a note or flag in the response to indicate that the address was "corrected", as well as the corrected address?