---
title: "User Address Model"
description: "Recipient name and phone fields can represent another person so a business or driver can contact the intended recipient."
canonical: https://docs.ordering.co/api-reference/guides/addresses-model/
---

# User Address Model

A user address stores delivery or contact location data for one user. Recipient name and phone fields can represent another person so a business or driver can contact the intended recipient.

## Core operations

| Action | Method   | Resource                                  |
| ------ | -------- | ----------------------------------------- |
| List   | `GET`    | `/users/{user_id}/addresses`              |
| Find   | `GET`    | `/users/{user_id}/addresses/{address_id}` |
| Create | `POST`   | `/users/{user_id}/addresses`              |
| Update | `PUT`    | `/users/{user_id}/addresses/{address_id}` |
| Delete | `DELETE` | `/users/{user_id}/addresses/{address_id}` |

All five operations described here require authentication. List, find, and create enforce the user boundary for ordinary callers; administrators and agents can act across users. Update and delete may apply less restrictive parent checks; see their operation guides for the conditions that apply.

Representative fields include `id`, `user_id`, `name`, `middle_name`, `lastname`, `second_lastname`, `phone`, `cellphone`, `address`, `address_notes`, `zipcode`, `location`, `default`, `internal_number`, `tag`, `map_data`, `external_id`, and structured street, city, state, and country fields. Field requirements remain operation-specific.

Addresses can expose metafields through `params`. See [List address metafields](https://docs.ordering.co/api-reference/guides/testinput/) and [Extra attributes (Metafields)](https://docs.ordering.co/api-reference/guides/extra-attributes/). See the operation guide for the complete request and response schemas.