Contact Engineering & Support

The contact form on this page reaches the people who maintain the generator and the postal data behind it. There is no ticket queue and no sales team; messages are read by the same engineers who write the code.

What is worth writing about

Data corrections

The most useful message you can send is a wrong record. If a generated address pairs a ZIP code with a city that does not use it, names a county the city does not sit in, or uses an area code that has been retired or overlaid, that is a defect in the postal registry and it gets fixed. Include the exact record you were given — city, state, ZIP and county — because that is enough to reproduce it.

Bug reports

A tool that returns nothing, an export that produces a malformed file, an API endpoint that answers with the wrong shape, a page that breaks at a particular screen width. Say what you did, what you expected, and what happened instead.

Tool and API requests

If a generator or a field you need for testing is missing, say what you are testing and what the data has to satisfy. Requests that describe a real testing problem are far more likely to get built than requests that name a feature.

Integration questions

The REST API is free, needs no key, and is documented at the API reference. If something there is ambiguous, that is a documentation bug and worth reporting as one.

What to leave out

Please do not send personal data. This site exists so that testing does not require real names, real addresses or real customer records, and a support message is no different: describe the problem with the synthetic record that produced it. Messages are stored only for as long as it takes to answer them, as described in the Privacy Policy.

Sending programmatically

The form posts to /api/v1/contact, which accepts a JSON body with name, email, subject and message. It is rate limited in the same way as the rest of the API and requires no authentication.

Before you write

A good share of questions are already answered: the API documentation covers every endpoint with working examples, the USPS abbreviations reference covers suffix and unit-designator formatting, and the technical guides cover why validators reject addresses that look correct. If the answer is there and hard to find, that itself is worth telling us.