Release Date: November 18, 2025
Affected Endpoint: /property/auto-complete
Overview
This release introduces two important enhancements to the Address Auto-Complete API that improve flexibility and search accuracy:
Extended Character Limit: Query strings now support up to 50 characters (previously 25)
Intelligent Address Normalization: Automatic address normalization to improve suggestion matching
1. Extended Character Limit (25 → 50 Characters)
What Changed
The maximum allowed length for address search queries has been increased from 25 to 50 characters, enabling users to search with more complete address information.
Customer Impact
Before:
Queries were limited to 25 characters
Users received an error: "Invalid request. Query should not exceed 25 characters limit."
Longer street names or complete addresses couldn't be searched
Users had to abbreviate or truncate addresses to stay within the limit
After:
Queries can now be up to 50 characters long
More complete addresses can be searched without truncation
Better support for properties with longer street names
Improved user experience when typing full addresses
Example Use Cases
Previously Failed (>25 chars):
Query: "10326 Smugglers Cove, Aurora" Length: 30 characters Result: ERROR - "Query should not exceed 25 characters limit"
Now Supported:
Query: "10326 Smugglers Cove, Aurora, OH 44202" Length: 40 characters Result: SUCCESS - Returns matching address suggestions
Additional Examples:
"2128 Northwest 104th Way, Gainesville, FL" (43 chars) ✓ Now Supported "131 Pine Dr Pocono Lake, PA 18347" (34 chars) ✓ Now Supported "1917 Ridge Ave, Scranton, PA 18503" (35 chars) ✓ Now Supported
What You Should Do
Update Input Validation: If your application validates query length client-side, update the maximum allowed length from 25 to 50 characters
Improve User Experience: Consider allowing users to type more complete addresses for better matching
Update Error Handling: The error message for exceeding the limit now references 50 characters instead of 25
No Breaking Changes: Existing queries under 25 characters continue to work exactly as before
2. Intelligent Address Normalization
What Changed
The Address Auto-Complete API now automatically applies address normalization when the original search query doesn't return results. This helps match variations in how addresses are written.
How It Works
When you submit an address query:
First Attempt: The API searches for matches using your exact input
Smart Fallback: If no matches are found, the API normalizes the address and searches again
Results: You receive suggestions based on either the original or normalized search
This two-step process ensures you get results while still prioritizing exact matches.
Address Normalization Rules
The API intelligently normalizes common address variations:
What Gets Normalized:
Original | Normalized | Example |
Cove | Cv | "Smugglers Cove" → "Smugglers Cv" |
Northwest | NW | "Northwest 104th Way" → "NW 104th Way" |
Southeast | SE | "Southeast Avenue" → "SE Avenue" |
Northeast | NE | "Northeast Street" → "NE Street" |
Southwest | SW | "Southwest Road" → "SW Road" |
Boulevard | Blvd | "Main Boulevard" → "Main Blvd" |
Street | St | "Oak Street" → "Oak St" |
Avenue | Ave | "Park Avenue" → "Park Ave" |
Road | Rd | "Maple Road" → "Maple Rd" |
Drive | Dr | "Pine Drive" → "Pine Dr" |
Court | Ct | "Elm Court" → "Elm Ct" |
Circle | Cir | "Oak Circle" → "Oak Cir" |
What Does NOT Get Normalized:
The API specifically avoids overly aggressive normalization that could cause false matches:
❌ "Pine" does NOT become "PNE"
❌ "Lake" does NOT become "LK"
❌ "Ridge" does NOT become "RDG"
❌ Leading numbers are NOT removed
❌ Common words are preserved in full when they're part of the street name
This prevents incorrect suggestions like matching "Pine Dr" with "PNE Dr" or "Lake Ave" with "LK Ave".
Customer Impact
Before:
Exact address format matching was required
"10326 Smugglers Cove" wouldn't match "10326 Smugglers Cv"
"2128 Northwest 104th Way" wouldn't match "2128 NW 104th Way"
Users had to know the exact abbreviation format in the database
After:
Flexible address format matching
Common variations automatically matched
Improved suggestion accuracy
Better user experience - type addresses naturally
Real-World Examples
Example 1: Common Street Type Abbreviations
Your Search:
{
"query": "10326 Smugglers Cove, Aurora, OH"
}What Happens:
First search: "10326 Smugglers Cove, Aurora, OH" (no matches)
Normalizes to: "10326 Smugglers Cv, Aurora, OH"
Returns: Matching suggestions with normalized address
Response:
{
"suggestions": [
{
"formattedAddress": "10326 Smugglers Cv, Aurora, OH 44202",
"street": "10326 Smugglers Cv",
"city": "Aurora",
"state": "OH",
"zipcode": "44202"
}
]
}Example 2: Directional Abbreviations
Your Search:
{
"query": "2128 Northwest 104th Way, Gainesville, FL"
}What Happens:
First search: "2128 Northwest 104th Way, Gainesville, FL" (no matches)
Normalizes to: "2128 NW 104th Way, Gainesville, FL"
Returns: Matching suggestions with normalized address
Response:
{
"suggestions": [
{
"formattedAddress": "2128 NW 104th Way, Gainesville, FL 32606",
"street": "2128 NW 104th Way",
"city": "Gainesville",
"state": "FL",
"zipcode": "32606"
}
]
}Example 3: What Does NOT Match (By Design)
Your Search:
{
"query": "131 Pine Dr Pocono Lake, PA"
}What Happens:
First search: "131 Pine Dr Pocono Lake, PA" (checks for exact match)
Normalizes responsibly - preserves "Pine" and "Lake" as full words
Does NOT suggest: "131 PNE Dr Pocono LK, PA" ❌
Returns: Only true matches for "131 Pine Dr Pocono Lake, PA"
This prevents false matches that would confuse users or return incorrect properties.
Benefits
✅ Natural Language Input - Type addresses as you normally would
✅ Format Flexibility - No need to guess abbreviations
✅ Improved Match Rate - More suggestions returned
✅ Smart Normalization - Avoids false positives
✅ Backwards Compatible - Exact matches still prioritized
What You Should Do
Leverage Natural Input: Allow users to type addresses in their natural format - the API will handle normalization
Don't Pre-Normalize: Avoid pre-processing addresses on your end - let the API's intelligent normalization handle it
Update UI Guidance: You can remove instructions about using specific abbreviations
Test Edge Cases: Verify that your application handles both exact and normalized suggestion formats correctly
No Code Changes Required: This enhancement works automatically - no integration changes needed
Combined Benefits
When used together, these enhancements provide:
More Flexible Searches: Type longer, more complete addresses (up to 50 chars)
Better Match Rate: Automatic normalization finds results even with format variations
Improved User Experience: Less friction - users can type addresses naturally
Maintained Accuracy: Smart normalization prevents false matches
Zero Breaking Changes: Existing integrations continue to work without modification
API Behavior Summary
Search Flow
User Input (up to 50 chars) ↓ Exact Match Search ↓ Matches Found? → YES → Return Suggestions ↓ NO Apply Address Normalization ↓ Normalized Match Search ↓ Matches Found? → YES → Return Suggestions ↓ NO Return Empty Results
Character Limit Validation
Valid: 1-50 characters
Invalid: 0 characters (empty) or >50 characters
Error Message (if exceeded): "Invalid request. Query should not exceed 50 characters limit."
Migration Checklist
For Extended Character Limit
[ ] Updated client-side validation to allow up to 50 characters
[ ] Removed artificial truncation of longer addresses
[ ] Updated error messages to reference 50-character limit
[ ] Tested with addresses between 25-50 characters
For Address Normalization
[ ] Removed pre-processing/normalization from client code
[ ] Updated UI to allow natural address input (no abbreviation guidance needed)
[ ] Tested with various address formats (full vs abbreviated)
[ ] Verified suggestion display handles normalized results correctly
Frequently Asked Questions
Extended Character Limit
Q: Will my existing queries still work? A: Yes! All queries under 25 characters work exactly as before.
Q: What happens if I exceed 50 characters? A: You'll receive an error message indicating the limit. The new limit is 50 characters (previously 25).
Q: Are spaces counted in the character limit? A: Yes, all characters including spaces, commas, and punctuation are counted.
Q: Can I submit addresses longer than 50 characters? A: No. The maximum query length is 50 characters. Most complete addresses fit within this limit.
Address Normalization
Q: Will normalization change the addresses I receive in suggestions? A: The suggested addresses are always in the format stored in our property database. Normalization only affects the search process, not the suggestion results.
Q: Should I pre-normalize addresses before sending to the API? A: Not necessary. The API handles normalization automatically. Send addresses in their natural format.
Q: What if the normalized version is wrong? A: The API uses conservative normalization rules and only standard abbreviations. If you encounter issues, please contact support with specific examples.
Q: Will exact matches still be prioritized? A: Yes! The API first searches for exact matches. Normalization only happens if the exact search returns no results.
Q: Does normalization affect performance? A: The impact is minimal. Normalization only occurs when the initial exact search returns no results, acting as a smart fallback.
Q: Can I disable normalization for my requests? A: Currently, normalization is applied automatically to all requests when exact matches aren't found. This is designed to improve results without requiring configuration changes.
Q: Does normalization work with ZIP codes? A: ZIP codes are preserved exactly as entered and are not subject to normalization.
Support
If you have questions about these enhancements or need assistance:
Documentation: developer.batchdata.com
Support Email: support@batchdata.com
API Status: status.batchdata.com
Technical Notes
Character Limit Implementation
Validation occurs before any processing
UTF-8 encoding is used for character counting
Limit applies to the entire query string
Normalization Implementation
Applied after initial search returns no results
Uses USPS standard abbreviations
Preserves address semantics and structure
Does not modify original database records