How to design address fields in ChatGPT apps

Roughly half of all third-party apps in the ChatGPT App Store deal with location data in some form: 73 out of 147 apps, collectively exposing 222 address-related parameters for ChatGPT to work with. Most of them are handling it poorly.

That ratio is higher than you'd expect. Given what most ChatGPT apps do (search the web, manage tasks, generate images, write code), location isn't the first data type that comes to mind. But it makes sense once you look at the categories: travel apps need origins, destinations, and hotel locations; shopping apps need shipping addresses; food apps need delivery addresses; lifestyle apps need "near me" search. Location is one of the most pervasive data types in the ecosystem, and the way apps handle it varies wildly.

We dug into the metadata behind every one of those 222 parameters to understand how apps are telling ChatGPT to handle addresses. The short version: the majority rely on a single free-text string field, which forces ChatGPT to guess, concatenate, and hope for the best. The longer version has some useful takeaways for app developers.

Why Address Handling Matters in ChatGPT Apps

When a user tells ChatGPT "order me dinner to my apartment on 5th Ave," the app on the other end needs a usable address. But what counts as "usable" depends entirely on how the app's metadata defines its address fields.

If the metadata says "give me a single string called address," ChatGPT has to smoosh everything together: street, city, state, zip, all in one blob. If the user only said "5th Ave," ChatGPT either has to ask follow-up questions (if the metadata tells it to) or guess the rest.

This is already happening in some of the most popular apps in the store.

The Uber Eats Case Study: A Single String Does a Lot of Heavy Lifting

Here's what ChatGPT actually sees in the Uber Eats metadata when it needs to search for restaurants:

• App: Uber Eats
• Action: search
• Parameter: address
• Type: string (required)
• Description: "User's delivery address (for example: '123 Main St San Francisco CA 94102'). The agent must always explicitly ask the user for their delivery address before invoking this tool, unless the user has previously provided their address."

It's a single string field, so ChatGPT has to take whatever the user says and format it into something like 123 Main St San Francisco CA 94102, with no separation between street, city, state, and zip code.

To their credit, the metadata does instruct ChatGPT to ask for the address before making the call. But the format itself is fragile. If a user says "my place near Union Square," ChatGPT has no structured way to decompose that into components, validate them, or geocode the location. It just has to produce a single string and hope Uber Eats' backend can parse it.

There's no latitude/longitude fallback, no separate city or zip field, and no guidance on what to do with ambiguous input beyond "ask the user."

Structured vs. Unstructured: The Data Breakdown

Across all 73 apps with address-related parameters, we classified each app's approach into three categories:

The unstructured approach dominates, accounting for 45 out of 73 apps (62%). Nearly two-thirds of location-aware ChatGPT apps are asking an LLM to format addresses as a single concatenated string, with no field-level validation or decomposition. Our best hypothesis for why: it's the path of least resistance. A single string field is the simplest thing a developer can implement. You define one parameter, give it a description, and you're done. No schema to design, no field-level validation to wire up, no edge cases around which components are required versus optional. It's not the best approach for ChatGPT, but it's the fastest to ship.

The 19 apps using structured fields give ChatGPT separate parameters for each address component. This is meaningfully better: ChatGPT can ask the user for their city, then their state, then their zip, and slot each piece into the right field. If the user skips one, ChatGPT knows exactly which piece is missing.

The 9 mixed apps offer both: a text query for natural language input, plus structured fields as a fallback or supplement. This is the most resilient approach, and it's also the least common.

Certain app categories skew heavily toward location data. Travel is the clearest example: all 13 travel apps in the store use location parameters in some form. Shopping, Lifestyle, and Food categories also lean heavily on address and location fields, which makes sense given the real-world, place-dependent nature of those use cases.

Same Company, Different Approaches: Uber vs. Uber Eats

An interesting comparison: Uber and Uber Eats are built by the same company, but they handle location data in completely different ways.

While Uber Eats uses that single address string, Uber (the rides app) uses a LocationSpecification object with a text_query field plus optional geographic coordinates:

• Parameter type: LocationSpecification
• Description: "Origin location specification. At minimum text_query is required (must be non-vague like Space Needle Seattle not downtown). Optional: point with coordinates and confidence for more accurate results."

Two things stand out. First, Uber provides explicit guidance on specificity: it tells ChatGPT to use "Space Needle Seattle" rather than just "downtown." That one example in the metadata gives the model a clear signal about the expected level of detail.

Second, Uber supports optional coordinates (latitude, longitude, and a confidence score). If ChatGPT can geocode the user's input (or if the user provides coordinates directly), the app can use precise location data instead of relying on text parsing alone.

Same parent company, same general problem (getting a user from A to B, or getting food from a restaurant to a user), but the rides app gives ChatGPT structured, multi-layered location data while the food delivery app gives it a single string.

Best Practices for Address Fields in ChatGPT Apps

Based on our analysis of all 73 apps, the best address metadata tends to follow a few patterns:

1. Use structured fields for address components

Separate parameters for street, city, state, and zip code let ChatGPT validate each piece independently. If a user provides a city but not a zip, ChatGPT knows what's missing and can ask a targeted follow-up question.

2. Support coordinates as a fallback

Latitude and longitude fields enable precise geocoding. Even if the user's text input is ambiguous ("near the park"), ChatGPT can attempt to resolve it to coordinates before sending the request. Apps that accept both text and coordinates are the most resilient to ambiguous input.

3. Provide examples of expected specificity

Uber's metadata tells ChatGPT to use "Space Needle Seattle" instead of "downtown." This kind of inline guidance is cheap to add and measurably improves output quality. The model takes these examples seriously.

4. Instruct ChatGPT on what to do when input is incomplete

The best metadata doesn't just define fields, it tells ChatGPT how to behave. "Always ask the user for their city and state if not provided" is more useful than just marking a field as required.

What Better Uber Eats Metadata Could Look Like

Here's how Uber Eats could restructure its address handling to give ChatGPT more to work with:

{
  "address": {
    "street": {
      "type": "string",
      "required": true,
      "description": "Street address including number (e.g., '123 Main St'). The agent must ask the user for this if not provided."
    },
    "city": {
      "type": "string",
      "required": true,
      "description": "City name (e.g., 'San Francisco')."
    },
    "state": {
      "type": "string",
      "required": true,
      "description": "Two-letter state code (e.g., 'CA')."
    },
    "zip_code": {
      "type": "string",
      "required": false,
      "description": "Five-digit ZIP code (e.g., '94102'). If not provided, the system will attempt to resolve from city and state."
    },
    "coordinates": {
      "latitude": { "type": "number", "required": false },
      "longitude": { "type": "number", "required": false },
      "description": "Optional coordinates for precise delivery location. Use if the user provides a pin or exact location."
    }
  }
}

This version gives ChatGPT five separate fields instead of one. It provides examples for each. It makes zip code optional (since the backend can often resolve it). And it adds coordinate support for cases where text alone isn't enough.

Instead of ChatGPT producing 123 Main St San Francisco CA 94102 as a single blob, it can validate each component, ask targeted follow-ups for missing pieces, and provide coordinates when available.

The Bigger Picture

Address handling is a microcosm of a broader challenge in ChatGPT app design: how much structure should you give the model? Too little (a single string field), and you're relying on the LLM to do work your backend should handle. Too much (dozens of required fields), and you create friction that makes the app harder to invoke.

The apps that get this balance right tend to use structured fields with sensible defaults, provide inline examples, and include fallback options like coordinates. They treat the metadata not just as a schema, but as a set of instructions for how ChatGPT should interact with users.

With 222 address parameters across 73 apps (and growing), this is a design space that deserves more attention from app developers. We'll be tracking how these patterns evolve as the ecosystem matures.

Methodology

This analysis covers 147 third-party apps in the ChatGPT App Store as of February 2025. We excluded integrations built and maintained by OpenAI (like GitHub, Linear, Slack, and Google Workspace) to focus on apps that companies built and shipped independently.

Want access to the full dataset? Contact us to learn more.