This is the primary difference between Premium and Deluxe editions. Both include the same 40 fields (CenLat, CenLon, CensusBlockGroup), but the centroid coordinates come from very different data sources.

Premium Edition:

• Street-level centroid coordinates
• 80% completion across the dataset
• Best for: General mapping, proximity analysis, territory management, store locators
• Coordinates represent the approximate center of the address range on a street segment

Deluxe Edition:

• Building-based centroid coordinates (rooftop-level precision)
• 95% completion across the dataset
• Significantly higher accuracy - often precise to the actual building
• Best for: Precision delivery routing, enterprise geocoding, logistics optimization, high-accuracy applications

Completion rates by state: Mainland U.S. averages 97-99% completion for both editions. Military addresses (AA/AE/AP) are 99%+. Territories vary: Puerto Rico (88.66%), Guam (57%), Virgin Islands (8%), American Samoa and others below 1%.

Bottom line: If you need "good enough" coordinates for most mapping applications, Premium delivers excellent value. If you need the highest possible accuracy for logistics, routing, or precision applications - Deluxe is worth the investment.

View complete field comparison →

Transaction files contain only the records that changed since the previous month. They're much smaller than the full database files and allow you to efficiently maintain current data.

File naming convention:

2025-10-ZIP4-Update-Standard.zip → 2025-10-ZIP4-Update-Standard.csv
2025-10-ZIP4-Update-Premium.zip → 2025-10-ZIP4-Update-Premium.csv
2025-10-ZIP4-Update-Deluxe.zip → 2025-10-ZIP4-Update-Deluxe.csv

Format: YYYY-MM-ZIP4-Update-[Edition].zip

How updates work - The D/A pattern:

The USPS doesn't have an "Update" action code. Instead, they use a Delete-then-Add pattern:

• Delete (D): Remove the old record using the UpdateKey
• Add (A): Insert the new record with the same UpdateKey but updated data

It's annoying and antiquated, but it's how the USPS does it. Welcome to government data!

Processing logic:

1. Read transaction file
2. For each record:
   IF Action = 'D':
      DELETE FROM zip4_table WHERE UpdateKey = record.UpdateKey
   ELSE IF Action = 'A':
      INSERT INTO zip4_table VALUES (record data)
3. Commit changes

Typical change volume:

• Most months: 1-5% of records change
• December/January: Larger updates when Congressional District changes take effect (every 2 years)
• Growth areas: New developments get new ZIP+4 codes continuously
• Established areas: Mostly updates (splits, corrections) rather than net new codes

Pro tip: If you're using FTP automation, schedule downloads for the 5th of each month. We've never missed publishing on the 1st in many years, but occasionally there are republications to correct edge cases.

Every ZIP+4 purchase includes the corresponding ZIP Code Database to provide city names, area codes, time zones, and other data not included in the ZIP+4 files.

Edition pairings:

• ZIP+4 Standard → ZIP Code Database Standard
• ZIP+4 Premium → ZIP Code Database Deluxe
• ZIP+4 Deluxe → ZIP Code Database Deluxe

Note: You can upgrade to ZIP Code Database Business separately if needed.

What data comes from the ZIP Code Database?

• City Name: USPS preferred city name (may differ slightly from ZIP+4 addressing)
• City Aliases: Acceptable alternate city names for that ZIP
• Area Codes: Phone area codes serving that ZIP
• Time Zone: Time zone and DST observance
• County Details: Full county names (ZIP+4 only has FIPS codes)

Join relationships - three ways to connect:

SQL Example:

-- Primary join method
SELECT 
    z4.ZipCode,
    z4.Plus4Low,
    z4.StName,
    zc.City,
    zc.AreaCode,
    zc.TimeZone
FROM zip4_database z4
LEFT JOIN zipcode_database zc 
    ON z4.PreferredLastLineKey = zc.PreferredLastLineKey
WHERE z4.ZipCode = '10001';

Why the complexity? The USPS uses different key structures for different purposes. We keep all the keys in the data so you can join however makes sense for your use case. For most applications, stick with PreferredLastLineKey → PreferredLastLineKey.

Non-Deliverable (ND) ZIP+4 codes represent addresses where the USPS does not deliver mail. They account for approximately 1.35% of all records (~653,000 out of 48.5 million).

What makes a ZIP+4 non-deliverable?

• Vacant land with no structures
• Railroad right-of-ways
• Industrial zones without delivery service
• Areas where delivery infrastructure doesn't exist

How to identify ND codes:

ND codes are marked by "ND" in the Plus4Low and Plus4High fields:

ZipCode: 12345
Plus4Low: 14ND
Plus4High: 14ND

Are they temporary or permanent?

ND codes are generally permanent until an area gains delivery service or structures are built. They're not "under construction" placeholders - they represent areas that currently have no mail delivery capability.

How should developers handle ND codes?

• Address Validation: Filter OUT ND codes - they should not validate as deliverable addresses
• Database Loading: You can exclude them entirely, or keep them flagged as "non-deliverable" for reference
• User Messaging: If an address matches an ND ZIP+4, inform the user that USPS does not deliver to this location
• Alternative Delivery: The physical location exists, but USPS won't deliver. FedEx/UPS may serve the area - contact the recipient to confirm

USPS Guidance: The USPS explicitly states that mailers should not match addresses to non-delivery areas. CASS-certified software treats ND codes as invalid for delivery, so your validation logic should too.

The RecordType field indicates what kind of address record you're dealing with. Each type has different field characteristics and usage patterns.

Distribution across 48.5 million records:

Field characteristics by RecordType:

S (Street) - 67.44%: Standard street addressing. All street name fields populated, address ranges in Primary Low/High, coordinates available for most records. This is your typical "123 Main St" address.

H (High-Rise) - 29.61%: Multi-unit buildings. Uses Secondary Address fields (AddressSecondaryAbbr, AddressSecondaryLowNumber, AddressSecondaryHighNumber) for apartment/unit ranges. Example: "100 Park Ave, APT 101-125". Primary Low usually equals Primary High (single building).

P (PO Box) - 1.51%: Street name is literally "PO BOX". Box number range appears in AddressPrimaryLowNumber/HighNumber fields. No coordinates - PO Boxes don't have street locations. Filter these out if you're doing geocoding.

F (Firm) - 1.05%: Similar to High-Rise but for businesses receiving large mail volumes. The firm gets its own unique ZIP+4. May use secondary address fields for internal mail sorting (departments, floors). Example: Large corporate headquarters.

R (Rural Route) - 0.34%: Rural addressing. Street name shows "RR #" (Rural Route) or "HC #" (Highway Contract). Box numbers appear in Primary address range fields. Example: "RR 2 Box 123". Coordinates available at same rates as other types.

G (General Delivery) - 0.06%: USPS service for people without fixed addresses. Street name is always "GENERAL DELIVERY", no Primary address range, Plus4Low/High always "9999", OddEven always "B". Rare but used in remote areas.

Developer tip: When building address validation, filter by RecordType first. Street (S) and High-Rise (H) cover 97% of records and use standard validation logic. The other types need special handling.

All coordinate fields use the WGS84 geodetic datum with 6 decimal places of precision.

Coordinate precision:

• 6 decimals: ±0.11 meters (~4 inches) precision
• Format: DECIMAL(11,8) for latitude, DECIMAL(11,8) for longitude
• Example: 40.748817, -73.985428 (Empire State Building)

Coordinate fields available:

IMPORTANT: Do NOT use FromLatitude/FromLongitude or ToLatitude/ToLongitude

These fields are legacy data from a USPS/Census collaborative project that was supposed to be updated annually but was abandoned around 2010. We kept them in the database for backward compatibility, but they are not maintained and should not be relied upon for any application.

What to use instead:

• Premium/Deluxe editions: Use CenLat and CenLon - these are actively maintained and highly accurate
• Standard edition: The From/To coordinates are your only option, but understand they're outdated. Consider upgrading to Premium for reliable coordinates.

Military ZIP+4 coordinates:

Military addresses (AA/AE/AP) do have coordinate data, but these should NOT be used for proximity analysis or mapping. The coordinates are administrative placeholders (often pointing to mail processing centers) rather than actual overseas base locations.

Bottom line: For any geocoding, mapping, or distance calculations - use CenLat/CenLon from Premium or Deluxe editions only. The From/To coordinates are reference-only at best.

All files use UTF-8 encoding without BOM (byte order mark).

Why UTF-8? It handles international characters and special symbols that appear in U.S. place names (yes, even domestically we have diacritics and special characters).

Database-specific recommendations:

• MySQL: Use utf8mb4 character set and utf8mb4_unicode_ci collation
• PostgreSQL: Set ENCODING 'UTF8' when creating the database
• SQL Server: Use NVARCHAR data types for full Unicode support
• SQLite: UTF-8 is the default - no special configuration needed

CSV Import:

-- MySQL LOAD DATA example
LOAD DATA LOCAL INFILE 'ZIP4-NY.csv'
INTO TABLE zip4_database
CHARACTER SET utf8mb4
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\r\n'
IGNORE 1 ROWS;

The files don't have a BOM (byte order mark), which is good - BOMs can cause parsing issues in many tools. Just specify UTF-8 and you're set.

UpdateKey is a unique identifier assigned to each ZIP+4 record by the USPS. It's the only field guaranteed to be unique across the entire dataset.

Why not use ZIP+Plus4Low+Plus4High?

Multiple records can share the same ZIP+4 combination if they represent different address ranges or record types. The UpdateKey ensures you can uniquely identify each record.

UpdateKey characteristics:

• Format: VARCHAR(10) - alphanumeric
• Globally unique: No duplicates across all 48.5 million records
• Persistent: When a record is updated, it keeps the same UpdateKey (Delete then Add pattern)
• Essential for transaction files: Used to match deletions and additions during monthly updates

Database schema recommendation:

CREATE TABLE zip4_database (
    UpdateKey VARCHAR(10) PRIMARY KEY,
    ZipCode CHAR(5) NOT NULL,
    Plus4Low CHAR(4),
    Plus4High CHAR(4),
    -- ... other fields
    INDEX idx_zipcode (ZipCode),
    INDEX idx_carrier_route (CarrierRoute)
);

Pro tip: Always create an index on ZipCode for query performance, even though UpdateKey is the primary key. Most applications query by ZIP code, not UpdateKey.

We use empty strings ("") rather than NULL values.

Why? Years ago, we made a decision to use empty strings because they're easier to understand for non-technical users. Looking back, we probably should have used NULL, but we've maintained this approach for consistency and backward compatibility. You can convert them to NULL in your database if you prefer.

Key patterns:

• Empty strings appear when data is not applicable or cannot be determined with reasonable certainty
• ZipCode and UpdateKey are never empty - these are required fields
• CarrierRoute is never empty - 100% of records have this field populated
• Secondary address fields (AddressSecondary*) are empty unless RecordType is H or F
• Street direction fields (StPreDirAbbr, StPostDirAbbr) are empty when not applicable

Query patterns:

-- Find records with no building/firm name
SELECT * FROM zip4_database 
WHERE BuildingFirmName = '';

-- In application code
if (record.StPreDirAbbr === '' || record.StPreDirAbbr === null) {
    // No pre-directional
}

Philosophy: We only include data we can confirm with reasonable certainty. If we don't know something, we leave it empty rather than guessing. It irritates some customers, but it's the right thing to do.

These fields are legacy data that should NOT be used for any application.

The backstory: Around 2008-2010, the USPS partnered with the Census Bureau to provide address range endpoint coordinates. The plan was to update these annually. We waited years being told updates would resume, but they never did. The data became stale around 2010 and has not been maintained since.

What's affected:

• FromLatitude / FromLongitude - Start point of address range
• ToLatitude / ToLongitude - End point of address range
• CensusTract - Also from this same abandoned project
• CensusBlock - Also from this same abandoned project

Why we kept them: Legacy compatibility. Some customers have applications built around these fields, and we try not to remove columns once we've added them. But for new implementations - don't use them.

What to use instead:

• For coordinates: Use CenLat and CenLon (Premium/Deluxe only) - these are actively maintained and accurate
• For census geography: Use CensusBlockGroup (Premium/Deluxe only) - this is current and reliable

Bottom line: Treat FromLatitude, FromLongitude, ToLatitude, ToLongitude, CensusTract, and CensusBlock as reference-only at best, unusable at worst. Do not build applications around this data. Upgrade to Premium or Deluxe for reliable geographic coordinates.

Address ranges define which house numbers on a street segment share the same ZIP+4 code.

The three key fields:

• AddressPrimaryLowNumber - Start of the range
• AddressPrimaryHighNumber - End of the range
• AddressPrimaryOddEven - Which numbers in the range are included

OddEven values:

Validation logic example:

function validateAddress(houseNumber, record) {
    // Check if number is in range
    if (houseNumber < record.AddressPrimaryLowNumber || 
        houseNumber > record.AddressPrimaryHighNumber) {
        return false;
    }
    
    // Check odd/even match
    const isOdd = houseNumber % 2 === 1;
    const isEven = houseNumber % 2 === 0;
    
    if (record.AddressPrimaryOddEven === 'O' && !isOdd) {
        return false;
    }
    if (record.AddressPrimaryOddEven === 'E' && !isEven) {
        return false;
    }
    // 'B' matches both, so no check needed
    
    return true; // Valid!
}

Special cases:

• Single address: When Low = High, this represents a single address (not a range). Common for Firm (F) and High-Rise (H) records.
• Alphanumeric addresses: Some addresses include letters (e.g., "123A Main St"). These are stored as-is in VARCHAR fields.
• Secondary addresses: High-Rise (H) and Firm (F) records also use AddressSecondaryLowNumber/HighNumber/OddEven for apartment/suite ranges.

Pro tip: When building address validation, always check both the range AND the odd/even indicator. A house number can be numerically within the range but still invalid if it doesn't match the parity requirement.

It varies significantly, but most months see 1-5% of records change.

Typical patterns:

• Regular months: 1-3% change rate (~500K-1.5M records)
• December/January: Larger updates (5-10%) when Congressional District changes take effect every 2 years
• Growth areas: Continuously adding new ZIP+4 codes for new developments
• Established areas: Mostly updates (splits, corrections) rather than net new codes

What causes changes:

• New construction and developments
• ZIP+4 code splits (one code becomes multiple)
• Carrier route reassignments
• Address range corrections
• Congressional district updates (every 2 years)
• Street name changes or corrections

No meaningful monthly pattern beyond the Congressional District cycle. Some months are quiet, some are busier - it depends on what's happening across the country. The USPS updates reflect real-world changes in the addressing system.

Planning tip: Budget for processing 1-5% of your records each month. The transaction files make this efficient - you're not reloading the entire 48.5M record dataset.

Yes, all military ZIP+4 codes are included in every edition.

Military "state" codes:

• AA: Armed Forces Americas (Central & South America)
• AE: Armed Forces Europe (Europe, Middle East, Africa, Canada)
• AP: Armed Forces Pacific (Pacific theater)

Record counts:

• AA: 10,638 records
• AE: 66,618 records
• AP: 15,482 records
• Total: ~93,000 military ZIP+4 codes

What's included:

• Full address range data (AddressPrimaryLowNumber/HighNumber)
• Carrier route information
• All standard fields are populated
• Coordinates exist (but see warning below)

Coordinate warning:

Military records DO have coordinate data (latitude/longitude), but these coordinates should NOT be used for proximity analysis or mapping. The coordinates are administrative placeholders - often pointing to mail processing centers or collection points (like Miami for some AA codes) rather than actual overseas base locations.

How to identify military records:

SELECT * FROM zip4_database 
WHERE State IN ('AA', 'AE', 'AP');

Delivery notes:

Military addresses use the standard ZIP+4 format but are delivered differently. The USPS collects mail domestically and transports it to military transit hubs, where the military handles final delivery to bases, ships, and deployed units worldwide.

P.S. We are a veteran-owned business! 🇺🇸

PO Box records (RecordType = P) have a different structure than street addresses. They represent Post Office Box ranges, not physical street locations.

PO Box record characteristics:

• RecordType: Always P
• StName: Always "PO BOX" (literal text)
• Box number range: Appears in AddressPrimaryLowNumber/HighNumber fields
• No street components: StPreDirAbbr, StSuffixAbbr, StPostDirAbbr are empty
• No coordinates: Latitude/Longitude fields are typically empty - PO Boxes don't have street locations
• Carrier Route: Uses "P" prefix (e.g., P001, P002)

Example PO Box record:

RecordType: P
StName: PO BOX
AddressPrimaryLowNumber: 1
AddressPrimaryHighNumber: 120
Plus4Low: 0001
Plus4High: 0120
CarrierRoute: P001

Query to find PO Box records:

SELECT * FROM zip4_database 
WHERE RecordType = 'P';

Validation differences:

• Match box number to AddressPrimaryLowNumber/HighNumber range
• Don't try to validate street name components
• Skip geocoding/mapping - there's no physical location to plot

Common mistake: Trying to geocode PO Box addresses. Filter these out (RecordType = 'P') before any coordinate-based operations to avoid errors or nonsense results.

Rural Route (RR) and Highway Contract (HC) addresses are used in less densely populated areas where traditional street addressing isn't practical.

Rural Route record characteristics:

• RecordType: R
• StName format: "RR #" or "HC #" (e.g., "RR 2", "HC 73")
• Box numbers: Appear in AddressPrimaryLowNumber/HighNumber fields
• Address format: "RR 2 Box 123" or "HC 73 Box 456"
• Coordinates: Available at same completion rates as other record types (~98%)
• Carrier Route: Uses "R" prefix (e.g., R001, R002)

Example Rural Route record:

RecordType: R
StName: RR 2
AddressPrimaryLowNumber: 100
AddressPrimaryHighNumber: 199
Plus4Low: 9501
Plus4High: 9599
CarrierRoute: R002

RR vs HC:

• Rural Route (RR): Traditional rural delivery route served by USPS carrier
• Highway Contract (HC): Rural delivery contracted to private carriers who serve remote areas
• Both function similarly for addressing purposes

Validation logic:

Match the box number (not a house number) against the address range. Example: "HC 73 Box 125" would match a record with StName = "HC 73", AddressPrimaryLowNumber = 100, AddressPrimaryHighNumber = 150.

Rural addressing represents only 0.34% of records (164K), but it's essential for serving remote communities. Many of these addresses have since converted to city-style addressing through the LACS program.

Our data is USPS-licensed ZIP+4 data, but our database product is NOT CASS-certified.

What is CASS?

CASS (Coding Accuracy Support System) is a USPS certification program that evaluates address-matching software for accuracy in assigning ZIP+4 codes, delivery points, and carrier routes. Software must pass annual tests to maintain certification.

Can you use this data for address validation?

Yes - you can build address validation systems using this data. The data itself is from the USPS and is the same data used by CASS-certified tools. With proper implementation, you can achieve 95%+ validation accuracy.

What's the catch?

• No USPS postage discounts: You cannot claim automation rates for bulk mailings without CASS-certified processing
• No USPS verification: The USPS won't recognize your validation as "official"
• You're on your own: We provide the data and technical support, but implementing accurate validation logic is your responsibility

Standard validation workflow:

1. Parse input address into components (number, pre-direction, street name, suffix, post-direction, secondary)
2. Standardize components per USPS rules (uppercase, abbreviate suffixes, normalize directionals)
3. Match street name and ZIP code to find candidate records
4. Check if house number falls within AddressPrimaryLowNumber/HighNumber range
5. Verify odd/even parity matches AddressPrimaryOddEven indicator
6. Return the corresponding Plus4Low/Plus4High values

When you NEED CASS certification:

• Claiming USPS automation postage discounts for bulk mail
• Meeting contractual requirements for "CASS-certified" address validation
• Regulatory compliance in certain industries

When our data works fine:

• Internal address validation for CRM, e-commerce, or databases
• Shipping with private carriers (FedEx, UPS) who don't require CASS
• Address standardization and cleansing
• Geographic analysis and territory assignment

Bottom line: Use our data for internal validation, standardization, and analysis. If you need USPS postage discounts or official CASS certification, you'll need CASS-certified software (which uses this same USPS data under the hood).

USPS Publication 28 defines official addressing standards. Our data follows these standards, and your validation/standardization should too.

Case requirements:

• All uppercase for address components
• Example: "123 Main St" becomes "123 MAIN ST"

Street suffix abbreviations:

See USPS Publication 28 Appendix C for the complete list of 100+ suffix abbreviations.

Directional abbreviations:

Secondary unit designators:

• Apartment → APT
• Suite → STE
• Unit → UNIT
• Floor → FL
• Building → BLDG

Punctuation and spacing:

• Remove periods from abbreviations (ST not S.T.)
• Single space between components
• No commas (except between city and state)

Example standardization:

Input:  "123 North Main Street, Apartment 5B"
Output: "123 N MAIN ST APT 5B"

Our database uses these standards throughout. Match your input addresses to these standards before querying for best results.

General Delivery is a USPS service for people without fixed addresses. Mail is addressed to "General Delivery" and held at a post office for pickup.

General Delivery record characteristics:

• RecordType: G
• StName: Always "GENERAL DELIVERY" (literal text)
• No address ranges: AddressPrimaryLowNumber/HighNumber are empty
• No secondary address: All AddressSecondary* fields are empty
• AddressPrimaryOddEven: Always B (both)
• Plus4Low/Plus4High: Always 9999
• Coordinates: Many have CenLat/CenLon, but NO FromLatitude/FromLongitude/ToLatitude/ToLongitude

When is it used?

• Travelers without permanent addresses
• Remote areas without street delivery
• Temporary situations (between moves, etc.)

How rare is it?

Only 0.06% of records (27,300 out of 48.5 million) are General Delivery. It's a niche service but important for serving transient populations and remote communities.

General Delivery mail is addressed: "John Doe, General Delivery, CITY, STATE ZIP". No street address needed.

Mainland U.S. states average 97-99% centroid completion. U.S. territories struggle with significantly lower completion rates.

Territory completion rates (Premium & Deluxe):

Why the difference?

Data collection and geocoding infrastructure in U.S. territories lags behind the mainland. Factors include:

• Limited parcel data availability
• Less comprehensive address databases
• Geographic challenges (remote islands, dense jungles)
• Smaller populations = less commercial geocoding investment

What this means for your application:

• Mainland U.S. and Puerto Rico: Excellent centroid coverage
• Guam: Moderate coverage (57%) - usable for many applications
• VI/AS/MP/FM/PW/MH: Very limited - don't rely on centroids for these territories

Pro tip: If your application serves U.S. territories, consider falling back to ZIP Code-level coordinates (from the included ZIP Code Database) when CenLat/CenLon are empty in the ZIP+4 data.

Yes, we maintain historical ZIP+4 data with the same field structure as current data.

Historical data availability by edition:

• Standard Edition: September 2007 - Present (18 years of monthly snapshots)
• Deluxe Edition: December 2010 - Present (15 years of monthly snapshots)
• Premium Edition: December 2018 - Present (7 years of monthly snapshots)

Why different start dates?

We began offering Standard in 2007. Deluxe was introduced in 2010. Premium was created in 2018 as a mid-tier option after licensing changes made Deluxe significantly more expensive - giving cost-conscious customers a street-level centroid option.

What's included:

• Complete monthly snapshots (not just changes)
• Same 62-state file structure
• Identical field structure to current data
• Purchase individual months or the complete archive

Common use cases:

• Analyzing address changes over time
• Validating addresses as of specific historical dates
• Research and longitudinal studies
• Backfilling geocoding for historical addresses

Learn more about Historical ZIP+4 Data →

Yes, absolutely. This is a downloadable database product, not a cloud API service. Once you download the data, it's yours to use locally.

What you can do:

• Import into your own database (MySQL, PostgreSQL, SQL Server, etc.)
• Use completely offline - no internet connection required
• No per-query fees or rate limits
• No dependency on our servers or uptime
• Keep the data forever (though we recommend monthly updates for accuracy)

Updates:

Your purchase includes 12 months of monthly updates. After your subscription period:

• You can continue using your last downloaded version indefinitely
• Renew subscription to receive continued monthly updates
• The data doesn't "expire" or stop working

Perfect for:

• Applications requiring guaranteed uptime
• High-volume processing (millions of addresses)
• Environments with limited internet access
• Avoiding per-query costs of API services
• Complete control over your addressing infrastructure

License: Fully licensed for your organization's internal use. No external API dependencies. Your data, your infrastructure, your control.

LACS (Locatable Address Conversion System) identifies rural addresses that have been converted to city-style addressing.

What is LACS?

The USPS program that converts rural route addresses (e.g., "RR 2 Box 123") into standard street addresses (e.g., "456 County Road 789"). This improves mail delivery efficiency and emergency services response.

LACSStatus values:

Why it matters:

• Old rural addresses may still be in your database
• LACS records provide the new, correct address format
• Helps with address cleansing and standardization
• Emergency services use the new addresses

Query example:

-- Find all LACS-converted addresses in a ZIP
SELECT * FROM zip4_database 
WHERE ZipCode = '12345' 
  AND LACSStatus = 'L';

Most developers can ignore this field unless you're specifically dealing with rural address conversion or address cleansing projects.

Multi-unit buildings use secondary address fields to represent apartment/suite/unit ranges.

Which records have secondary addresses?

• RecordType H (High-Rise): Apartment buildings, condos, multi-unit residential
• RecordType F (Firm): Businesses with internal mail sorting (floors, departments, suites)

Street (S), PO Box (P), Rural (R), and General Delivery (G) records do NOT use secondary address fields.

Secondary address fields:

• AddressSecondaryAbbr - Unit designator (APT, STE, FL, UNIT, etc.)
• AddressSecondaryLowNumber - Start of unit range
• AddressSecondaryHighNumber - End of unit range
• AddressSecondaryOddEven - O/E/B indicator for unit numbers

Example High-Rise record:

RecordType: H
StName: PARK AVE
AddressPrimaryLowNumber: 100
AddressPrimaryHighNumber: 100  (single building)
AddressSecondaryAbbr: APT
AddressSecondaryLowNumber: 101
AddressSecondaryHighNumber: 125
AddressSecondaryOddEven: O  (odd apartments only)
Plus4Low: 5401
Plus4High: 5413

This represents: "100 Park Ave, APT 101-125 (odd numbers)"

Validation logic:

1. Match primary address: "100 Park Ave"
2. Check if AddressSecondaryAbbr is populated
3. If yes, validate unit number against:
   - AddressSecondaryLowNumber/HighNumber range
   - AddressSecondaryOddEven indicator
4. Return appropriate Plus4 code

Common issue: Missing apartment numbers in multi-unit buildings will fail validation or return incomplete ZIP+4 codes. Always collect and validate secondary address information for H and F record types.

The BaseAlternateCode distinguishes between preferred (Base) and alternate address formats.

Values:

When does this occur?

Some addresses can be written multiple ways, and the USPS designates one as "preferred":

• Example 1: "100 N Main St" (Base) vs "100 Main St N" (Alternate)
• Example 2: "PO Box 100" (Base) vs "100 Main St" (Alternate street address for same location)

Best practice:

-- Prioritize Base records in validation
SELECT * FROM zip4_database 
WHERE ZipCode = '12345'
  AND StName = 'MAIN'
  AND (BaseAlternateCode = 'B' OR BaseAlternateCode = '')
ORDER BY BaseAlternateCode DESC;

In practice, most records have an empty BaseAlternateCode field - this only appears when multiple formats exist for the same deliverable address. When in doubt, prefer 'B' over 'A'.

Extremely rare, but yes - a few edge cases exist, primarily in the Connecticut/Massachusetts border area.

How rare is this?

Out of 48.5 million ZIP+4 records, only a handful of ZIP codes span state boundaries. When they do, individual ZIP+4 codes typically stay within one state - the 5-digit ZIP crosses, but the +4 segments divide along state lines.

Why does this happen?

• USPS mail routing convenience (roads cross state lines)
• Post office service areas that logically serve both sides of a border
• Historical boundaries that don't align with current geography

Connecticut planning regions:

Connecticut replaced counties with planning regions in 2022, which creates additional complexity when working with historical data or cross-state analysis. See our Connecticut planning regions guide for details.

For developers:

• Don't assume ZIP code = single state
• Always check the State field in the data
• For multi-state queries, search by ZIP code across multiple state files

This is such a rare edge case that most applications can safely ignore it. But if you're building compliance systems or need perfect accuracy - be aware it exists.

FinanceNumber is the USPS facility finance code for the post office serving that ZIP+4 code.

What it represents:

• Unique identifier for the USPS facility (post office, processing center)
• Used internally by USPS for cost accounting and revenue tracking
• Links mail volume to specific facilities

Format:

• VARCHAR(6) - 6-character alphanumeric code
• Example: 012345

Common use cases:

• USPS contracts: If you have agreements with specific USPS facilities
• Mail logistics: Tracking which facility processes your mail
• Cost analysis: Allocating postage costs by facility
• Operational planning: Understanding USPS service territories

For most developers:

You can safely ignore this field. It's specialized data that matters primarily to bulk mailers with USPS facility-level contracts or organizations analyzing USPS operational data.

We include it because it's in the USPS data, but 95% of our customers never use it.

The GovernmentBuilding field identifies federal, state, and local government facilities.

Values:

Use cases:

• Government contractors: Identifying official addresses for deliveries
• Compliance: Special handling rules for government mail
• Analysis: Mapping government facilities by region
• Security: Flagging government addresses for special processing

Query example:

-- Find all federal government addresses in DC
SELECT * FROM zip4_database 
WHERE State = 'DC' 
  AND GovernmentBuilding = 'A';

Most records have an empty GovernmentBuilding field - this is specialized metadata that matters primarily for government contractors and specific compliance scenarios.

With 48.5 million records, proper indexing is critical for query performance.

Essential indexes:

-- Primary key (already indexed)
PRIMARY KEY (UpdateKey)

-- ZIP code lookups (most common query)
CREATE INDEX idx_zipcode ON zip4_database(ZipCode);

-- Carrier route queries
CREATE INDEX idx_carrier_route ON zip4_database(CarrierRoute);

-- State-based filtering
CREATE INDEX idx_state ON zip4_database(State);

-- Composite index for street name lookups
CREATE INDEX idx_zip_street ON zip4_database(ZipCode, StName);

-- RecordType filtering
CREATE INDEX idx_recordtype ON zip4_database(RecordType);

Query optimization tips:

• Always filter by ZipCode first - narrows from 48.5M to ~1,500 records
• Use EXPLAIN/ANALYZE to verify index usage
• Avoid wildcard searches at the start of strings (LIKE '%Main%')
• Consider partitioning by State for very large deployments

Hardware recommendations:

• RAM: 8GB+ dedicated to database server
• Storage: SSD strongly recommended for query speed
• Database size: ~15-20GB uncompressed (varies by edition)

Fast query example:

-- Good: Uses index on ZipCode
SELECT * FROM zip4_database 
WHERE ZipCode = '10001' 
  AND StName = 'BROADWAY'
  AND AddressPrimaryLowNumber <= 123
  AND AddressPrimaryHighNumber >= 123;

-- Slow: No ZipCode filter, full table scan
SELECT * FROM zip4_database 
WHERE StName = 'MAIN ST';

Pro tip: Most address validation queries complete in under 10ms with proper indexes. If your queries are slow, you're probably missing the ZipCode index.

No, the license is for your organization's internal use only.

What you CAN do:

• Use within your organization across all departments and subsidiaries
• Build internal applications and tools
• Validate and standardize addresses for your own records
• Provide address validation services to your customers (as a feature of your application)
• Use for analysis, reporting, and business intelligence

What you CANNOT do:

• Resell or redistribute the raw data files
• Provide the data to third parties or clients
• Include the data in products you sell to others
• Share your login credentials or allow others to download
• Post the data publicly on websites or file-sharing services

Common scenarios:

ALLOWED: You're a SaaS company building an address validation feature into your application. Customers use YOUR tool, which uses OUR data internally. The customers never see or download the raw ZIP+4 database.

NOT ALLOWED: You're a consultant who wants to provide the ZIP+4 database files to your clients as part of a project deliverable. Each client needs their own license.

Need to provide data to clients?

We offer volume licensing and reseller programs. Contact us at info@zip-codes.com to discuss options.

License enforcement: We take license compliance seriously. Violations can result in license termination and legal action. When in doubt, contact us - we're happy to clarify.

UrbanizationKey is used exclusively for Puerto Rico addresses to identify urbanization names (neighborhoods/districts).

What is an Urbanization?

In Puerto Rico, an "urbanización" is a community or neighborhood name that appears in mailing addresses. It's similar to a subdivision name but more formal and required by USPS for proper mail delivery.

Address format example:

JUAN GARCIA
URB LAS LOMAS 123 CALLE PRINCIPAL
SAN JUAN PR 00926-1234

"URB LAS LOMAS" is the urbanization name

How to use UrbanizationKey:

The UrbanizationKey in the ZIP+4 Database joins to the PreferredLastLineKey in the ZIP Code Database to retrieve the actual urbanization name.

-- Get urbanization name for Puerto Rico addresses
SELECT 
    z4.ZipCode,
    z4.StName,
    zc.City AS UrbanizationName
FROM zip4_database z4
LEFT JOIN zipcode_database zc 
    ON z4.UrbanizationKey = zc.PreferredLastLineKey
WHERE z4.State = 'PR' 
  AND z4.UrbanizationKey != '';

When is it populated?

• Only for Puerto Rico (State = 'PR') records
• Only when an urbanization name exists for that address
• Empty for all other states and territories

Why it matters:

• Required for accurate Puerto Rico address validation
• USPS requires urbanization names when applicable
• Improves delivery accuracy in PR

Unless you're specifically working with Puerto Rico addresses, you can ignore this field. For PR addresses, it's essential for proper USPS formatting.