What Is postalCode in DefinedRegion?

postalCode is a Text property that identifies one exact postal code within a DefinedRegion.

In shipping schema, the DefinedRegion can become a shipping destination or origin for a rate, delivery time, restriction, or service condition. The exact code supplies membership; it does not contain the shipping outcome itself.

Use an exact postal code when one code needs different treatment from its surrounding state, prefix, or range. US examples include a local-delivery ZIP, a remote surcharge ZIP, or a service exclusion. Store the value as Text so identifiers such as 00501 remain intact.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Model one complete code.
• Preserve every character.
• Tie it to a real shipping outcome.

Use the free backlink checker to find linked commerce pages before changing their shipping coverage.

Primary specification: Schema.org definition for postalCode.

postalCode is the precise choice when one complete code defines the operational region.

postalCode belongs on DefinedRegion, which is then referenced by a shippingDestination or shippingOrigin property.

Do not attach an exact postal code directly to Product, Offer, ShippingService, or ShippingConditions without the DefinedRegion layer. The region supplies country and optional state context and makes the code interpretable as geographic membership.

The same postalCode property also appears on other schema types, including PostalAddress, but a customer or warehouse address serves a different intent. For shipping coverage, use DefinedRegion rather than publishing a street-level address.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Choose the shipping parent.
2. Create a DefinedRegion.
3. Set addressCountry.
4. Add postalCode.
5. Validate the full graph.

Review DefinedRegion in shipping schema for the parent model.

Correct nesting distinguishes a coverage code from an ordinary mailing address.

Use an exact postal code when one complete code has a distinct shipping outcome that cannot be represented truthfully by a broader state, prefix, or continuous range.

Exact codes are appropriate for isolated service areas, special local delivery, remote surcharges, carrier exclusions, or a gap inside an otherwise broad region. They are also useful as exception records that override a general rule.

Do not enumerate thousands of individual ZIPs if one verified region or range expresses identical coverage. Precision should reduce false matches, not create an unmaintainable policy. Measure the source data shape before selecting the representation.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• List the intended members.
• Compare exact, prefix, range, and state sets.
• Choose the simplest exact set.
• Retain exception precedence.

Exact postal codes work best for true single-code distinctions, not as a substitute for region modeling.

Exact postal codes must be stored as Text because they are identifiers whose leading zeros, letters, spaces, and punctuation can be meaningful.

Converting US ZIP 00501 to integer 501 changes the code. Numeric types also fail for postal systems containing letters. Even a five-digit US ZIP should remain a string through database reads, templates, JSON serialization, and comparisons.

Validation should round-trip codes through the same publication pipeline used by production. Check that spreadsheet imports, analytics exports, and application serializers do not coerce values. A valid final string cannot recover the original once a leading zero was lost upstream.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Declare the source column as text.
2. Reject numeric coercion.
3. Preserve meaningful formatting.
4. Round-trip the rendered value.
5. Compare with checkout input.

Text storage protects the identity of every exact postal code from source to rendered markup.

Use the same ZIP granularity that the shipping engine can support consistently, usually five-digit ZIP for broad US commerce and ZIP+4 only for a verified sub-ZIP rule.

ZIP+4 can identify a smaller delivery segment, but customer entry, carrier normalization, and checkout matching may collapse it to five digits. Publishing a nine-digit exception is risky if the page or shipping engine cannot reproduce that distinction.

When ZIP+4 is operationally required, define its formatting and compare hyphenated and unhyphenated inputs. Test the base five-digit ZIP to ensure it does not inherit a narrow promise. Do not expose a customer's private delivery address as coverage data.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Confirm checkout granularity.
• Define hyphen normalization.
• Test base ZIP separately.
• Avoid address-level leakage.

ZIP+4 is appropriate only when the shipping outcome truly depends on and consistently matches the extended code.

An exact postalCode should act as a narrow inclusion or exclusion when it overlaps a broader prefix, range, state, or country rule, using deterministic precedence.

A general range may provide standard shipping while one exact ZIP carries a remote surcharge. Another exact ZIP may be excluded. If the policy engine does not define specificity, the same address can match contradictory rates, times, or availability outcomes.

Document whether a narrow exact rule overrides a broad rule and ensure markup and checkout apply the same decision. Array order is not a durable precedence model. Test the exact code and neighboring codes that should continue using the broad condition.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Enumerate all matching rules.
2. Rank by documented specificity.
3. Resolve one outcome.
4. Test neighboring codes.
5. Add regression cases.

Compare postalCodePrefix and postalCodeRange before choosing the rule.

Exact-code exceptions are safe when precedence preserves the surrounding broader coverage.

Exact postal codes affect shipping by selecting a DefinedRegion whose surrounding rule supplies the rate, delivery time, service, or exclusion.

The code itself does not carry a price or duration. A local ZIP can select same-day delivery, a remote ZIP can select a surcharge, and an unsupported ZIP can select doesNotShip. Keep each outcome tied to the same current shipping authority used by checkout.

When a code changes zones, update the source policy and regenerate markup together. Test the exact code, a nearby code in the old zone, and a nearby code in the new zone. This confirms the repair did not shift an unintended boundary.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Resolve geographic match first.
• Apply the shipping outcome.
• Compare with checkout.
• Retest after zone updates.

Review doesNotShip for exact-code exclusions.

An exact postal code remains useful only when its attached shipping outcome matches the live policy.

Common mistakes include numeric coercion, leading-zero loss, missing country context, incomplete ZIP values, unsupported ZIP+4 assumptions, duplicate exact rules, stale exceptions, and checkout mismatches.

Another mistake is using an exact postal code when the intended region is actually a prefix or range, forcing hundreds of duplicate records. The reverse mistake broadens a one-ZIP exception into an entire code family and creates false availability.

Syntax validation cannot confirm that the code exists, is active, belongs to the declared region, or receives the stated shipping outcome. Operational evidence must come from current facility, carrier, rate, and checkout systems.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Extract every code and parent.
2. Validate format by country.
3. Find duplicates and overlaps.
4. Compare policy outcomes.
5. Repair the authority.

postalCode defects require identity, geography, precedence, and checkout validation together.