> For the complete documentation index, see [llms.txt](https://docs.zingg.ai/zingg/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zingg.ai/zingg/zingg-concepts/zingg-configuration/field-definition/match-types/pincode-match.md).

# PINCODE Match

Matches postal and ZIP codes across the common format variants they appear in 5-digit, 9-digit with hyphen, and others. The right choice for postal code fields instead of EXACT or FUZZY.

### What `PINCODE` does

`PINCODE` splits a value on the first hyphen, keeps only the part before it, and compares that prefix for exact equality. It is not a fuzziness dial sitting between `EXACT` and `FUZZY` - it's exact-match on a preprocessed string, where the preprocessing is "truncate at the first hyphen." Concretely, this models the **US ZIP+4 format specifically**: "12345-6789" is compared as just "12345", since the "-6789" is a discardable delivery-route extension in that format.

A null or blank value on either side is an automatic match.

**This is not a general international postal-code normalizer.** The hyphen-truncation logic assumes the part after the hyphen is always a discardable suffix. That's true for US ZIP+4, but many countries use a hyphen as a meaningful separator where *both* halves matter - for example, Polish postal codes ("00-950" vs "00-123") or Portuguese ones. On those formats, `PINCODE` truncates both sides down to "00" and reports a match, silently collapsing two genuinely different postal codes. See the table and "When not to use" below.

### What `PINCODE` matches and what it does not

<table><thead><tr><th valign="top">Value A</th><th valign="top">Value B</th><th valign="top">Match?</th></tr></thead><tbody><tr><td valign="top">94102</td><td valign="top">94102-1234</td><td valign="top">Yes - both truncate to "94102"</td></tr><tr><td valign="top">94102</td><td valign="top">94103</td><td valign="top">No - "94102" vs "94103"</td></tr><tr><td valign="top">EC1A 1BB</td><td valign="top">EC1A1BB</td><td valign="top">No - neither string has a hyphen, so both pass through unsplit</td></tr><tr><td valign="top">110001</td><td valign="top">110001</td><td valign="top">Yes - Indian PIN code, identical</td></tr><tr><td valign="top">94102</td><td valign="top">941-02</td><td valign="top">No - "94102" vs "941" ("941-02" truncates to "941", discarding "02")</td></tr><tr><td valign="top">00-950</td><td valign="top">00-123</td><td valign="top">Yes - a false match. Both truncate to "00"; this is the Polish-postal-code failure case</td></tr><tr><td valign="top">[null]</td><td valign="top">94102</td><td valign="top">Yes - null/blank on either side auto-matches</td></tr></tbody></table>

### When to use `PINCODE`

<details>

<summary><strong>Postal code, ZIP code, PIN code fields</strong></summary>

Any field containing a postal code or PIN code. `PINCODE` is always preferable to `EXACT` (which misses format variants) or `FUZZY` (which introduces tolerance that causes false matches between nearby but different codes).

This is the only match type specifically designed for postal codes.

</details>

### When not to use `PINCODE`

<details>

<summary><strong>Phone numbers or other numeric codes</strong></summary>

`PINCODE` is designed for postal codes specifically. For phone numbers, use `FUZZY` or `NUMERIC`. For product codes with numeric components, use `NUMERIC_WITH_UNITS` or `NUMERIC`.

</details>

<details>

<summary><strong>Hyphenated postal codes where both halves are significant</strong></summary>

`PINCODE`'s hyphen handling is US-ZIP+4-specific: it assumes anything after the first hyphen is a discardable suffix. Many countries' formats don't work that way - Polish postal codes ("00-950" vs "00-123") use the hyphen as a meaningful internal separator, and `PINCODE` would truncate both down to "00" and report a false match.

If your postal code format uses a hyphen where both sides carry meaning, use `EXACT` instead, or normalise the format upstream before matching.

</details>

{% hint style="success" icon="right-long" %}
**Related types:**

* `EXACT` - use when format is guaranteed consistent
* `NUMERIC` - for other numeric identifier fields
* `NULL_OR_BLANK` - combine when postal codes are often missing

**Read more:** [Match Types](/zingg/zingg-concepts/zingg-configuration/field-definition/match-types.md)
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zingg.ai/zingg/zingg-concepts/zingg-configuration/field-definition/match-types/pincode-match.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
