---
title: "PATCH /v1/{+name}"
method: PATCH
path: "/v1/{+name}"
tags: ["projects"]
---

# PATCH /v1/{+name}

`PATCH /v1/{+name}`

Updates select fields of a `Registration` resource, notably `labels`. To update other fields, use the appropriate custom update method: * To update management settings, see `ConfigureManagementSettings` * To update DNS configuration, see `ConfigureDnsSettings` * To update contact information, see `ConfigureContactSettings`

## Path parameters

- `name` string, required

## Query parameters

- `updateMask` string
- `validateOnly` boolean

## Request body

- Registration — The `Registration` resource facilitates managing and configuring domain name registrations. There are several ways to create a new `Registration` resource: To create a new `Registration` resource, find a suitable domain name by calling the `SearchDomains` method with a query to see available domain name options. After choosing a name, call `RetrieveRegisterParameters` to ensure availability and obtain information like pricing, which is needed to build a call to `RegisterDomain`. Another way to create a new `Registration` is to transfer an existing domain from another registrar (Deprecated: For more information, see [Cloud Domains feature deprecation](https://cloud.google.com/domains/docs/deprecations/feature-deprecations)). First, go to the current registrar to unlock the domain for transfer and retrieve the domain's transfer authorization code. Then call `RetrieveTransferParameters` to confirm that the domain is unlocked and to get values needed to build a call to `TransferDomain`. Finally, you can create a new `Registration` by importing an existing domain managed with [Google Domains](https://domains.google/) (Deprecated: For more information, see [Cloud Domains feature deprecation](https://cloud.google.com/domains/docs/deprecations/feature-deprecations)). First, call `RetrieveImportableDomains` to list domains to which the calling user has sufficient access. Then call `ImportDomain` on any domain names you want to use with Cloud Domains.
  - `dnsSettings` DnsSettings — Defines the DNS configuration of a `Registration`, including name servers, DNSSEC, and glue records.
    - `googleDomainsDns` GoogleDomainsDns — Deprecated: For more information, see [Cloud Domains feature deprecation](https://cloud.google.com/domains/docs/deprecations/feature-deprecations). Configuration for using the free DNS zone provided by Google Domains as a `Registration`'s `dns_provider`. You cannot configure the DNS zone itself using the API. To configure the DNS zone, go to [Google Domains](https://domains.google/).
      - `dsState` 'DS_STATE_UNSPECIFIED' | 'DS_RECORDS_UNPUBLISHED' | 'DS_RECORDS_PUBLISHED' — Required. The state of DS records for this domain. Used to enable or disable automatic DNSSEC.
      - `dsRecords` DsRecord[] — Output only. The list of DS records published for this domain. The list is automatically populated when `ds_state` is `DS_RECORDS_PUBLISHED`, otherwise it remains empty.
        - `digest` string — The digest generated from the referenced DNSKEY.
        - `keyTag` integer — The key tag of the record. Must be set in range 0 -- 65535.
        - `digestType` 'DIGEST_TYPE_UNSPECIFIED' | 'SHA1' | 'SHA256' | 'GOST3411' | 'SHA384' — The hash function used to generate the digest of the referenced DNSKEY.
        - `algorithm` 'ALGORITHM_UNSPECIFIED' | 'RSAMD5' | 'DH' | 'DSA' | 'ECC' | 'RSASHA1' | 'DSANSEC3SHA1' | 'RSASHA1NSEC3SHA1' | 'RSASHA256' | 'RSASHA512' | 'ECCGOST' | 'ECDSAP256SHA256' | 'ECDSAP384SHA384' | 'ED25519' | 'ED448' | 'INDIRECT' | 'PRIVATEDNS' | 'PRIVATEOID' — The algorithm used to generate the referenced DNSKEY.
      - `nameServers` string[] — Output only. A list of name servers that store the DNS zone for this domain. Each name server is a domain name, with Unicode domain names expressed in Punycode format. This field is automatically populated with the name servers assigned to the Google Domains DNS zone.
    - `googleDomainsRedirectsDataAvailable` boolean — Output only. Indicates if this `Registration` has configured one of the following deprecated Google Domains DNS features: * Domain forwarding (HTTP `301` and `302` response status codes), * Email forwarding. See https://cloud.google.com/domains/docs/deprecations/feature-deprecations for more details. If any of these features is enabled call the `RetrieveGoogleDomainsForwardingConfig` method to get details about the feature's configuration. A forwarding configuration might not work correctly if required DNS records are not present in the domain's authoritative DNS Zone.
    - `glueRecords` GlueRecord[] — The list of glue records for this `Registration`. Commonly empty.
      - `hostName` string — Required. Domain name of the host in Punycode format.
      - `ipv4Addresses` string[] — List of IPv4 addresses corresponding to this host in the standard decimal format (e.g. `198.51.100.1`). At least one of `ipv4_address` and `ipv6_address` must be set.
      - `ipv6Addresses` string[] — List of IPv6 addresses corresponding to this host in the standard hexadecimal format (e.g. `2001:db8::`). At least one of `ipv4_address` and `ipv6_address` must be set.
    - `customDns` CustomDns — Configuration for an arbitrary DNS provider.
      - `dsRecords` DsRecord[] — The list of DS records for this domain, which are used to enable DNSSEC. The domain's DNS provider can provide the values to set here. If this field is empty, DNSSEC is disabled.
        - `digest` string — The digest generated from the referenced DNSKEY.
        - `keyTag` integer — The key tag of the record. Must be set in range 0 -- 65535.
        - `digestType` 'DIGEST_TYPE_UNSPECIFIED' | 'SHA1' | 'SHA256' | 'GOST3411' | 'SHA384' — The hash function used to generate the digest of the referenced DNSKEY.
        - `algorithm` 'ALGORITHM_UNSPECIFIED' | 'RSAMD5' | 'DH' | 'DSA' | 'ECC' | 'RSASHA1' | 'DSANSEC3SHA1' | 'RSASHA1NSEC3SHA1' | 'RSASHA256' | 'RSASHA512' | 'ECCGOST' | 'ECDSAP256SHA256' | 'ECDSAP384SHA384' | 'ED25519' | 'ED448' | 'INDIRECT' | 'PRIVATEDNS' | 'PRIVATEOID' — The algorithm used to generate the referenced DNSKEY.
      - `nameServers` string[] — Required. A list of name servers that store the DNS zone for this domain. Each name server is a domain name, with Unicode domain names expressed in Punycode format.
  - `issues` string[] — Output only. The set of issues with the `Registration` that require attention.
  - `createTime` string, google-datetime — Output only. The creation timestamp of the `Registration` resource.
  - `supportedPrivacy` string[] — Output only. Set of options for the `contact_settings.privacy` field that this `Registration` supports.
  - `labels` object — Set of labels associated with the `Registration`.
  - `domainProperties` string[] — Output only. Special properties of the domain.
  - `transferFailureReason` 'TRANSFER_FAILURE_REASON_UNSPECIFIED' | 'TRANSFER_FAILURE_REASON_UNKNOWN' | 'EMAIL_CONFIRMATION_FAILURE' | 'DOMAIN_NOT_REGISTERED' | 'DOMAIN_HAS_TRANSFER_LOCK' | 'INVALID_AUTHORIZATION_CODE' | 'TRANSFER_CANCELLED' | 'TRANSFER_REJECTED' | 'INVALID_REGISTRANT_EMAIL_ADDRESS' | 'DOMAIN_NOT_ELIGIBLE_FOR_TRANSFER' | 'TRANSFER_ALREADY_PENDING' — Output only. Deprecated: For more information, see [Cloud Domains feature deprecation](https://cloud.google.com/domains/docs/deprecations/feature-deprecations). The reason the domain transfer failed. Only set for domains in TRANSFER_FAILED state.
  - `expireTime` string, google-datetime — Output only. The expiration timestamp of the `Registration`.
  - `contactSettings` ContactSettings — Defines the contact information associated with a `Registration`. [ICANN](https://icann.org/) requires all domain names to have associated contact information. The `registrant_contact` is considered the domain's legal owner, and often the other contacts are identical.
    - `privacy` 'CONTACT_PRIVACY_UNSPECIFIED' | 'PUBLIC_CONTACT_DATA' | 'PRIVATE_CONTACT_DATA' | 'REDACTED_CONTACT_DATA' — Required. Privacy setting for the contacts associated with the `Registration`.
    - `adminContact` Contact — Details required for a contact associated with a `Registration`.
      - `postalAddress` PostalAddress — Represents a postal address, such as for postal delivery or payments addresses. With a postal address, a postal service can deliver items to a premise, P.O. box, or similar. A postal address is not intended to model geographical locations like roads, towns, or mountains. In typical usage, an address would be created by user input or from importing existing data, depending on the type of process. Advice on address input or editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput. - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, see: https://support.google.com/business/answer/6397478.
        - `organization` string — Optional. The name of the organization at the address.
        - `regionCode` string — Required. CLDR region code of the country/region of the address. This is never inferred and it is up to the user to ensure the value is correct. See https://cldr.unicode.org/ and https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html for details. Example: "CH" for Switzerland.
        - `recipients` string[] — Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
        - `sortingCode` string — Optional. Additional, country-specific, sorting code. This is not used in most regions. Where it is used, the value is either a string like "CEDEX", optionally followed by a number (for example, "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (Côte d'Ivoire).
        - `administrativeArea` string — Optional. Highest administrative subdivision which is used for postal addresses of a country or region. For example, this can be a state, a province, an oblast, or a prefecture. For Spain, this is the province and not the autonomous community (for example, "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. For example, in Switzerland, this should be left unpopulated.
        - `postalCode` string — Optional. Postal code of the address. Not all countries use or require postal codes to be present, but where they are used, they may trigger additional validation with other parts of the address (for example, state or zip code validation in the United States).
        - `revision` integer — The schema revision of the `PostalAddress`. This must be set to 0, which is the latest revision. All new revisions **must** be backward compatible with old revisions.
        - `addressLines` string[] — Unstructured address lines describing the lower levels of an address. Because values in `address_lines` do not have type information and may sometimes contain multiple values in a single field (for example, "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country or region of the address. In places where this can vary (for example, Japan), `address_language` is used to make it explicit (for example, "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). In this way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a `region_code` with all remaining information placed in the `address_lines`. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a `region_code` and `address_lines` and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).
        - `sublocality` string — Optional. Sublocality of the address. For example, this can be a neighborhood, borough, or district.
        - `languageCode` string — Optional. BCP-47 language code of the contents of this address (if known). This is often the UI language of the input form or is expected to match one of the languages used in the address' country/region, or their transliterated equivalents. This can affect formatting in certain countries, but is not critical to the correctness of the data and will never affect any validation or other non-formatting related operations. If this value is not known, it should be omitted (rather than specifying a possibly incorrect default). Examples: "zh-Hant", "ja", "ja-Latn", "en".
        - `locality` string — Optional. Generally refers to the city or town portion of the address. Examples: US city, IT comune, UK post town. In regions of the world where localities are not well defined or do not fit into this structure well, leave `locality` empty and use `address_lines`.
      - `phoneNumber` string — Required. Phone number of the contact in international format. For example, `"+1-800-555-0123"`.
      - `email` string — Required. Email address of the contact.
      - `faxNumber` string — Fax number of the contact in international format. For example, `"+1-800-555-0123"`.
    - `technicalContact` Contact — Details required for a contact associated with a `Registration`.
      - `postalAddress` PostalAddress — Represents a postal address, such as for postal delivery or payments addresses. With a postal address, a postal service can deliver items to a premise, P.O. box, or similar. A postal address is not intended to model geographical locations like roads, towns, or mountains. In typical usage, an address would be created by user input or from importing existing data, depending on the type of process. Advice on address input or editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput. - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, see: https://support.google.com/business/answer/6397478.
        - `organization` string — Optional. The name of the organization at the address.
        - `regionCode` string — Required. CLDR region code of the country/region of the address. This is never inferred and it is up to the user to ensure the value is correct. See https://cldr.unicode.org/ and https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html for details. Example: "CH" for Switzerland.
        - `recipients` string[] — Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
        - `sortingCode` string — Optional. Additional, country-specific, sorting code. This is not used in most regions. Where it is used, the value is either a string like "CEDEX", optionally followed by a number (for example, "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (Côte d'Ivoire).
        - `administrativeArea` string — Optional. Highest administrative subdivision which is used for postal addresses of a country or region. For example, this can be a state, a province, an oblast, or a prefecture. For Spain, this is the province and not the autonomous community (for example, "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. For example, in Switzerland, this should be left unpopulated.
        - `postalCode` string — Optional. Postal code of the address. Not all countries use or require postal codes to be present, but where they are used, they may trigger additional validation with other parts of the address (for example, state or zip code validation in the United States).
        - `revision` integer — The schema revision of the `PostalAddress`. This must be set to 0, which is the latest revision. All new revisions **must** be backward compatible with old revisions.
        - `addressLines` string[] — Unstructured address lines describing the lower levels of an address. Because values in `address_lines` do not have type information and may sometimes contain multiple values in a single field (for example, "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country or region of the address. In places where this can vary (for example, Japan), `address_language` is used to make it explicit (for example, "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). In this way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a `region_code` with all remaining information placed in the `address_lines`. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a `region_code` and `address_lines` and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).
        - `sublocality` string — Optional. Sublocality of the address. For example, this can be a neighborhood, borough, or district.
        - `languageCode` string — Optional. BCP-47 language code of the contents of this address (if known). This is often the UI language of the input form or is expected to match one of the languages used in the address' country/region, or their transliterated equivalents. This can affect formatting in certain countries, but is not critical to the correctness of the data and will never affect any validation or other non-formatting related operations. If this value is not known, it should be omitted (rather than specifying a possibly incorrect default). Examples: "zh-Hant", "ja", "ja-Latn", "en".
        - `locality` string — Optional. Generally refers to the city or town portion of the address. Examples: US city, IT comune, UK post town. In regions of the world where localities are not well defined or do not fit into this structure well, leave `locality` empty and use `address_lines`.
      - `phoneNumber` string — Required. Phone number of the contact in international format. For example, `"+1-800-555-0123"`.
      - `email` string — Required. Email address of the contact.
      - `faxNumber` string — Fax number of the contact in international format. For example, `"+1-800-555-0123"`.
    - `registrantContact` Contact — Details required for a contact associated with a `Registration`.
      - `postalAddress` PostalAddress — Represents a postal address, such as for postal delivery or payments addresses. With a postal address, a postal service can deliver items to a premise, P.O. box, or similar. A postal address is not intended to model geographical locations like roads, towns, or mountains. In typical usage, an address would be created by user input or from importing existing data, depending on the type of process. Advice on address input or editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput. - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, see: https://support.google.com/business/answer/6397478.
        - `organization` string — Optional. The name of the organization at the address.
        - `regionCode` string — Required. CLDR region code of the country/region of the address. This is never inferred and it is up to the user to ensure the value is correct. See https://cldr.unicode.org/ and https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html for details. Example: "CH" for Switzerland.
        - `recipients` string[] — Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
        - `sortingCode` string — Optional. Additional, country-specific, sorting code. This is not used in most regions. Where it is used, the value is either a string like "CEDEX", optionally followed by a number (for example, "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (Côte d'Ivoire).
        - `administrativeArea` string — Optional. Highest administrative subdivision which is used for postal addresses of a country or region. For example, this can be a state, a province, an oblast, or a prefecture. For Spain, this is the province and not the autonomous community (for example, "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. For example, in Switzerland, this should be left unpopulated.
        - `postalCode` string — Optional. Postal code of the address. Not all countries use or require postal codes to be present, but where they are used, they may trigger additional validation with other parts of the address (for example, state or zip code validation in the United States).
        - `revision` integer — The schema revision of the `PostalAddress`. This must be set to 0, which is the latest revision. All new revisions **must** be backward compatible with old revisions.
        - `addressLines` string[] — Unstructured address lines describing the lower levels of an address. Because values in `address_lines` do not have type information and may sometimes contain multiple values in a single field (for example, "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country or region of the address. In places where this can vary (for example, Japan), `address_language` is used to make it explicit (for example, "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). In this way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a `region_code` with all remaining information placed in the `address_lines`. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a `region_code` and `address_lines` and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).
        - `sublocality` string — Optional. Sublocality of the address. For example, this can be a neighborhood, borough, or district.
        - `languageCode` string — Optional. BCP-47 language code of the contents of this address (if known). This is often the UI language of the input form or is expected to match one of the languages used in the address' country/region, or their transliterated equivalents. This can affect formatting in certain countries, but is not critical to the correctness of the data and will never affect any validation or other non-formatting related operations. If this value is not known, it should be omitted (rather than specifying a possibly incorrect default). Examples: "zh-Hant", "ja", "ja-Latn", "en".
        - `locality` string — Optional. Generally refers to the city or town portion of the address. Examples: US city, IT comune, UK post town. In regions of the world where localities are not well defined or do not fit into this structure well, leave `locality` empty and use `address_lines`.
      - `phoneNumber` string — Required. Phone number of the contact in international format. For example, `"+1-800-555-0123"`.
      - `email` string — Required. Email address of the contact.
      - `faxNumber` string — Fax number of the contact in international format. For example, `"+1-800-555-0123"`.
  - `domainName` string — Required. Immutable. The domain name. Unicode domain names must be expressed in Punycode format.
  - `managementSettings` ManagementSettings — Defines renewal, billing, and transfer settings for a `Registration`.
    - `renewalMethod` 'RENEWAL_METHOD_UNSPECIFIED' | 'AUTOMATIC_RENEWAL' | 'MANUAL_RENEWAL' | 'RENEWAL_DISABLED' — Output only. The actual renewal method for this `Registration`. When `preferred_renewal_method` is set to `AUTOMATIC_RENEWAL`, the actual `renewal_method` can be equal to `RENEWAL_DISABLED`—for example, when there are problems with the billing account or reported domain abuse. In such cases, check the `issues` field on the `Registration`. After the problem is resolved, the `renewal_method` is automatically updated to `preferred_renewal_method` in a few hours.
    - `transferLockState` 'TRANSFER_LOCK_STATE_UNSPECIFIED' | 'UNLOCKED' | 'LOCKED' — This is the desired transfer lock state for this `Registration`. A transfer lock controls whether the domain can be transferred to another registrar. The transfer lock state of the domain is returned in the `effective_transfer_lock_state` property. The transfer lock state values might be different for the following reasons: * `transfer_lock_state` was updated only a short time ago. * Domains with the `TRANSFER_LOCK_UNSUPPORTED_BY_REGISTRY` state are in the list of `domain_properties`. These domains are always in the `UNLOCKED` state.
    - `effectiveTransferLockState` 'TRANSFER_LOCK_STATE_UNSPECIFIED' | 'UNLOCKED' | 'LOCKED' — Output only. The actual transfer lock state for this `Registration`.
    - `preferredRenewalMethod` 'RENEWAL_METHOD_UNSPECIFIED' | 'AUTOMATIC_RENEWAL' | 'MANUAL_RENEWAL' | 'RENEWAL_DISABLED' — Optional. The desired renewal method for this `Registration`. The actual `renewal_method` is automatically updated to reflect this choice. If unset or equal to `RENEWAL_METHOD_UNSPECIFIED`, the actual `renewalMethod` is treated as if it were set to `AUTOMATIC_RENEWAL`. You cannot use `RENEWAL_DISABLED` during resource creation, and you can update the renewal status only when the `Registration` resource has state `ACTIVE` or `SUSPENDED`. When `preferred_renewal_method` is set to `AUTOMATIC_RENEWAL`, the actual `renewal_method` can be set to `RENEWAL_DISABLED` in case of problems with the billing account or reported domain abuse. In such cases, check the `issues` field on the `Registration`. After the problem is resolved, the `renewal_method` is automatically updated to `preferred_renewal_method` in a few hours.
  - `name` string — Output only. Name of the `Registration` resource, in the format `projects/*/locations/*/registrations/`.
  - `registerFailureReason` 'REGISTER_FAILURE_REASON_UNSPECIFIED' | 'REGISTER_FAILURE_REASON_UNKNOWN' | 'DOMAIN_NOT_AVAILABLE' | 'INVALID_CONTACTS' — Output only. The reason the domain registration failed. Only set for domains in REGISTRATION_FAILED state.
  - `state` 'STATE_UNSPECIFIED' | 'REGISTRATION_PENDING' | 'REGISTRATION_FAILED' | 'TRANSFER_PENDING' | 'TRANSFER_FAILED' | 'IMPORT_PENDING' | 'ACTIVE' | 'SUSPENDED' | 'EXPORTED' | 'EXPIRED' — Output only. The state of the `Registration`
  - `pendingContactSettings` ContactSettings — Defines the contact information associated with a `Registration`. [ICANN](https://icann.org/) requires all domain names to have associated contact information. The `registrant_contact` is considered the domain's legal owner, and often the other contacts are identical.
    - `privacy` 'CONTACT_PRIVACY_UNSPECIFIED' | 'PUBLIC_CONTACT_DATA' | 'PRIVATE_CONTACT_DATA' | 'REDACTED_CONTACT_DATA' — Required. Privacy setting for the contacts associated with the `Registration`.
    - `adminContact` Contact — Details required for a contact associated with a `Registration`.
      - `postalAddress` PostalAddress — Represents a postal address, such as for postal delivery or payments addresses. With a postal address, a postal service can deliver items to a premise, P.O. box, or similar. A postal address is not intended to model geographical locations like roads, towns, or mountains. In typical usage, an address would be created by user input or from importing existing data, depending on the type of process. Advice on address input or editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput. - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, see: https://support.google.com/business/answer/6397478.
        - `organization` string — Optional. The name of the organization at the address.
        - `regionCode` string — Required. CLDR region code of the country/region of the address. This is never inferred and it is up to the user to ensure the value is correct. See https://cldr.unicode.org/ and https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html for details. Example: "CH" for Switzerland.
        - `recipients` string[] — Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
        - `sortingCode` string — Optional. Additional, country-specific, sorting code. This is not used in most regions. Where it is used, the value is either a string like "CEDEX", optionally followed by a number (for example, "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (Côte d'Ivoire).
        - `administrativeArea` string — Optional. Highest administrative subdivision which is used for postal addresses of a country or region. For example, this can be a state, a province, an oblast, or a prefecture. For Spain, this is the province and not the autonomous community (for example, "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. For example, in Switzerland, this should be left unpopulated.
        - `postalCode` string — Optional. Postal code of the address. Not all countries use or require postal codes to be present, but where they are used, they may trigger additional validation with other parts of the address (for example, state or zip code validation in the United States).
        - `revision` integer — The schema revision of the `PostalAddress`. This must be set to 0, which is the latest revision. All new revisions **must** be backward compatible with old revisions.
        - `addressLines` string[] — Unstructured address lines describing the lower levels of an address. Because values in `address_lines` do not have type information and may sometimes contain multiple values in a single field (for example, "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country or region of the address. In places where this can vary (for example, Japan), `address_language` is used to make it explicit (for example, "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). In this way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a `region_code` with all remaining information placed in the `address_lines`. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a `region_code` and `address_lines` and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).
        - `sublocality` string — Optional. Sublocality of the address. For example, this can be a neighborhood, borough, or district.
        - `languageCode` string — Optional. BCP-47 language code of the contents of this address (if known). This is often the UI language of the input form or is expected to match one of the languages used in the address' country/region, or their transliterated equivalents. This can affect formatting in certain countries, but is not critical to the correctness of the data and will never affect any validation or other non-formatting related operations. If this value is not known, it should be omitted (rather than specifying a possibly incorrect default). Examples: "zh-Hant", "ja", "ja-Latn", "en".
        - `locality` string — Optional. Generally refers to the city or town portion of the address. Examples: US city, IT comune, UK post town. In regions of the world where localities are not well defined or do not fit into this structure well, leave `locality` empty and use `address_lines`.
      - `phoneNumber` string — Required. Phone number of the contact in international format. For example, `"+1-800-555-0123"`.
      - `email` string — Required. Email address of the contact.
      - `faxNumber` string — Fax number of the contact in international format. For example, `"+1-800-555-0123"`.
    - `technicalContact` Contact — Details required for a contact associated with a `Registration`.
      - `postalAddress` PostalAddress — Represents a postal address, such as for postal delivery or payments addresses. With a postal address, a postal service can deliver items to a premise, P.O. box, or similar. A postal address is not intended to model geographical locations like roads, towns, or mountains. In typical usage, an address would be created by user input or from importing existing data, depending on the type of process. Advice on address input or editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput. - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, see: https://support.google.com/business/answer/6397478.
        - `organization` string — Optional. The name of the organization at the address.
        - `regionCode` string — Required. CLDR region code of the country/region of the address. This is never inferred and it is up to the user to ensure the value is correct. See https://cldr.unicode.org/ and https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html for details. Example: "CH" for Switzerland.
        - `recipients` string[] — Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
        - `sortingCode` string — Optional. Additional, country-specific, sorting code. This is not used in most regions. Where it is used, the value is either a string like "CEDEX", optionally followed by a number (for example, "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (Côte d'Ivoire).
        - `administrativeArea` string — Optional. Highest administrative subdivision which is used for postal addresses of a country or region. For example, this can be a state, a province, an oblast, or a prefecture. For Spain, this is the province and not the autonomous community (for example, "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. For example, in Switzerland, this should be left unpopulated.
        - `postalCode` string — Optional. Postal code of the address. Not all countries use or require postal codes to be present, but where they are used, they may trigger additional validation with other parts of the address (for example, state or zip code validation in the United States).
        - `revision` integer — The schema revision of the `PostalAddress`. This must be set to 0, which is the latest revision. All new revisions **must** be backward compatible with old revisions.
        - `addressLines` string[] — Unstructured address lines describing the lower levels of an address. Because values in `address_lines` do not have type information and may sometimes contain multiple values in a single field (for example, "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country or region of the address. In places where this can vary (for example, Japan), `address_language` is used to make it explicit (for example, "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). In this way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a `region_code` with all remaining information placed in the `address_lines`. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a `region_code` and `address_lines` and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).
        - `sublocality` string — Optional. Sublocality of the address. For example, this can be a neighborhood, borough, or district.
        - `languageCode` string — Optional. BCP-47 language code of the contents of this address (if known). This is often the UI language of the input form or is expected to match one of the languages used in the address' country/region, or their transliterated equivalents. This can affect formatting in certain countries, but is not critical to the correctness of the data and will never affect any validation or other non-formatting related operations. If this value is not known, it should be omitted (rather than specifying a possibly incorrect default). Examples: "zh-Hant", "ja", "ja-Latn", "en".
        - `locality` string — Optional. Generally refers to the city or town portion of the address. Examples: US city, IT comune, UK post town. In regions of the world where localities are not well defined or do not fit into this structure well, leave `locality` empty and use `address_lines`.
      - `phoneNumber` string — Required. Phone number of the contact in international format. For example, `"+1-800-555-0123"`.
      - `email` string — Required. Email address of the contact.
      - `faxNumber` string — Fax number of the contact in international format. For example, `"+1-800-555-0123"`.
    - `registrantContact` Contact — Details required for a contact associated with a `Registration`.
      - `postalAddress` PostalAddress — Represents a postal address, such as for postal delivery or payments addresses. With a postal address, a postal service can deliver items to a premise, P.O. box, or similar. A postal address is not intended to model geographical locations like roads, towns, or mountains. In typical usage, an address would be created by user input or from importing existing data, depending on the type of process. Advice on address input or editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput. - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, see: https://support.google.com/business/answer/6397478.
        - `organization` string — Optional. The name of the organization at the address.
        - `regionCode` string — Required. CLDR region code of the country/region of the address. This is never inferred and it is up to the user to ensure the value is correct. See https://cldr.unicode.org/ and https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html for details. Example: "CH" for Switzerland.
        - `recipients` string[] — Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
        - `sortingCode` string — Optional. Additional, country-specific, sorting code. This is not used in most regions. Where it is used, the value is either a string like "CEDEX", optionally followed by a number (for example, "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (Côte d'Ivoire).
        - `administrativeArea` string — Optional. Highest administrative subdivision which is used for postal addresses of a country or region. For example, this can be a state, a province, an oblast, or a prefecture. For Spain, this is the province and not the autonomous community (for example, "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. For example, in Switzerland, this should be left unpopulated.
        - `postalCode` string — Optional. Postal code of the address. Not all countries use or require postal codes to be present, but where they are used, they may trigger additional validation with other parts of the address (for example, state or zip code validation in the United States).
        - `revision` integer — The schema revision of the `PostalAddress`. This must be set to 0, which is the latest revision. All new revisions **must** be backward compatible with old revisions.
        - `addressLines` string[] — Unstructured address lines describing the lower levels of an address. Because values in `address_lines` do not have type information and may sometimes contain multiple values in a single field (for example, "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country or region of the address. In places where this can vary (for example, Japan), `address_language` is used to make it explicit (for example, "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). In this way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a `region_code` with all remaining information placed in the `address_lines`. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a `region_code` and `address_lines` and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).
        - `sublocality` string — Optional. Sublocality of the address. For example, this can be a neighborhood, borough, or district.
        - `languageCode` string — Optional. BCP-47 language code of the contents of this address (if known). This is often the UI language of the input form or is expected to match one of the languages used in the address' country/region, or their transliterated equivalents. This can affect formatting in certain countries, but is not critical to the correctness of the data and will never affect any validation or other non-formatting related operations. If this value is not known, it should be omitted (rather than specifying a possibly incorrect default). Examples: "zh-Hant", "ja", "ja-Latn", "en".
        - `locality` string — Optional. Generally refers to the city or town portion of the address. Examples: US city, IT comune, UK post town. In regions of the world where localities are not well defined or do not fit into this structure well, leave `locality` empty and use `address_lines`.
      - `phoneNumber` string — Required. Phone number of the contact in international format. For example, `"+1-800-555-0123"`.
      - `email` string — Required. Email address of the contact.
      - `faxNumber` string — Fax number of the contact in international format. For example, `"+1-800-555-0123"`.

## Response `200`

Successful response

---

[API](https://skmtc.net/google/apis/domains.md) · [All operations](https://skmtc.net/google/apis/domains/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/google/domains/versions/96ed971a98da/schema)
