Registers a new domain name and creates a corresponding Registration resource. Call RetrieveRegisterParameters first to check availability of the domain name and determine parameters like price that are needed to build a call to this method. A successful call creates a Registration resource in state REGISTRATION_PENDING, which resolves to ACTIVE within 1-2 minutes, indicating that the domain was successfully registered. If the resource ends up in state REGISTRATION_FAILED, it indicates that the domain was not registered successfully, and you can safely delete the resource and retry registration.

Scopes

You will need authorization for the https://www.googleapis.com/auth/cloud-platform scope to make a valid call.

If unset, the scope for this method defaults to https://www.googleapis.com/auth/cloud-platform. You can set the scope for this method like this: domains1-beta1 --scope <scope> projects locations-registrations-register ...

Required Scalar Argument

  • <parent> (string)
    • Required. The parent resource of the Registration. Must be in the format projects/*/locations/*.

Required Request Value

The request value is a data-structure with various fields. Each field may be a simple scalar or another data-structure. In the latter case it is advised to set the field-cursor to the data-structure's field to specify values more concisely.

For example, a structure like this:

RegisterDomainRequest:
  contact-notices: [string]
  domain-notices: [string]
  registration:
    contact-settings:
      admin-contact:
        email: string
        fax-number: string
        phone-number: string
        postal-address:
          address-lines: [string]
          administrative-area: string
          language-code: string
          locality: string
          organization: string
          postal-code: string
          recipients: [string]
          region-code: string
          revision: integer
          sorting-code: string
          sublocality: string
      privacy: string
      registrant-contact:
        email: string
        fax-number: string
        phone-number: string
        postal-address:
          address-lines: [string]
          administrative-area: string
          language-code: string
          locality: string
          organization: string
          postal-code: string
          recipients: [string]
          region-code: string
          revision: integer
          sorting-code: string
          sublocality: string
      technical-contact:
        email: string
        fax-number: string
        phone-number: string
        postal-address:
          address-lines: [string]
          administrative-area: string
          language-code: string
          locality: string
          organization: string
          postal-code: string
          recipients: [string]
          region-code: string
          revision: integer
          sorting-code: string
          sublocality: string
    create-time: string
    dns-settings:
      custom-dns:
        name-servers: [string]
      google-domains-dns:
        ds-state: string
        name-servers: [string]
    domain-name: string
    expire-time: string
    issues: [string]
    labels: { string: string }
    management-settings:
      preferred-renewal-method: string
      renewal-method: string
      transfer-lock-state: string
    name: string
    pending-contact-settings:
      admin-contact:
        email: string
        fax-number: string
        phone-number: string
        postal-address:
          address-lines: [string]
          administrative-area: string
          language-code: string
          locality: string
          organization: string
          postal-code: string
          recipients: [string]
          region-code: string
          revision: integer
          sorting-code: string
          sublocality: string
      privacy: string
      registrant-contact:
        email: string
        fax-number: string
        phone-number: string
        postal-address:
          address-lines: [string]
          administrative-area: string
          language-code: string
          locality: string
          organization: string
          postal-code: string
          recipients: [string]
          region-code: string
          revision: integer
          sorting-code: string
          sublocality: string
      technical-contact:
        email: string
        fax-number: string
        phone-number: string
        postal-address:
          address-lines: [string]
          administrative-area: string
          language-code: string
          locality: string
          organization: string
          postal-code: string
          recipients: [string]
          region-code: string
          revision: integer
          sorting-code: string
          sublocality: string
    register-failure-reason: string
    state: string
    supported-privacy: [string]
    transfer-failure-reason: string
  validate-only: boolean
  yearly-price:
    currency-code: string
    nanos: integer
    units: string

can be set completely with the following arguments which are assumed to be executed in the given order. Note how the cursor position is adjusted to the respective structures, allowing simple field names to be used most of the time.

  • -r . contact-notices=accusam
    • The list of contact notices that the caller acknowledges. The notices needed here depend on the values specified in registration.contact_settings.
    • Each invocation of this argument appends the given value to the array.
  • domain-notices=amet
    • The list of domain notices that you acknowledge. Call RetrieveRegisterParameters to see the notices that need acknowledgement.
    • Each invocation of this argument appends the given value to the array.
  • registration.contact-settings.admin-contact email=erat
    • Required. Email address of the contact.
  • fax-number=dolores
    • Fax number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • phone-number=erat
    • Required. Phone number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • postal-address address-lines=accusam
    • 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 (e.g. "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). 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).
    • Each invocation of this argument appends the given value to the array.
  • administrative-area=sea
    • 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. Specifically, for Spain this is the province and not the autonomous community (e.g. "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. E.g. in Switzerland this should be left unpopulated.
  • language-code=takimata
    • 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=lorem
    • Optional. Generally refers to the city/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.
  • organization=et
    • Optional. The name of the organization at the address.
  • postal-code=at
    • 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 (e.g. state/zip validation in the U.S.A.).
  • recipients=dolor
    • Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
    • Each invocation of this argument appends the given value to the array.
  • region-code=et
    • 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.
  • revision=53
    • 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.
  • sorting-code=erat
    • 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 (e.g. "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).

  • sublocality=sea

    • Optional. Sublocality of the address. For example, this can be neighborhoods, boroughs, districts.

  • ... privacy=nonumy

    • Required. Privacy setting for the contacts associated with the Registration.
  • registrant-contact email=et
    • Required. Email address of the contact.
  • fax-number=gubergren
    • Fax number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • phone-number=justo
    • Required. Phone number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • postal-address address-lines=sea
    • 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 (e.g. "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). 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).
    • Each invocation of this argument appends the given value to the array.
  • administrative-area=consetetur
    • 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. Specifically, for Spain this is the province and not the autonomous community (e.g. "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. E.g. in Switzerland this should be left unpopulated.
  • language-code=sit
    • 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=aliquyam
    • Optional. Generally refers to the city/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.
  • organization=eos
    • Optional. The name of the organization at the address.
  • postal-code=at
    • 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 (e.g. state/zip validation in the U.S.A.).
  • recipients=dolores
    • Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
    • Each invocation of this argument appends the given value to the array.
  • region-code=consetetur
    • 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.
  • revision=39
    • 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.
  • sorting-code=dolor
    • 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 (e.g. "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).

  • sublocality=aliquyam

    • Optional. Sublocality of the address. For example, this can be neighborhoods, boroughs, districts.

  • ...technical-contact email=no

    • Required. Email address of the contact.
  • fax-number=amet.
    • Fax number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • phone-number=ipsum
    • Required. Phone number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • postal-address address-lines=lorem
    • 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 (e.g. "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). 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).
    • Each invocation of this argument appends the given value to the array.
  • administrative-area=accusam
    • 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. Specifically, for Spain this is the province and not the autonomous community (e.g. "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. E.g. in Switzerland this should be left unpopulated.
  • language-code=gubergren
    • 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=sadipscing
    • Optional. Generally refers to the city/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.
  • organization=at
    • Optional. The name of the organization at the address.
  • postal-code=sit
    • 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 (e.g. state/zip validation in the U.S.A.).
  • recipients=duo
    • Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
    • Each invocation of this argument appends the given value to the array.
  • region-code=sit
    • 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.
  • revision=18
    • 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.
  • sorting-code=et
    • 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 (e.g. "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).

  • sublocality=rebum.

    • Optional. Sublocality of the address. For example, this can be neighborhoods, boroughs, districts.

  • .... create-time=dolor

    • Output only. The creation timestamp of the Registration resource.

  • dns-settings.custom-dns name-servers=lorem

    • 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.
    • Each invocation of this argument appends the given value to the array.

  • ..google-domains-dns ds-state=justo

    • Required. The state of DS records for this domain. Used to enable or disable automatic DNSSEC.

  • name-servers=amet.

    • 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.
    • Each invocation of this argument appends the given value to the array.

  • ... domain-name=no

    • Required. Immutable. The domain name. Unicode domain names must be expressed in Punycode format.
  • expire-time=nonumy
    • Output only. The expiration timestamp of the Registration.
  • issues=sed
    • Output only. The set of issues with the Registration that require attention.
    • Each invocation of this argument appends the given value to the array.
  • labels=key=kasd
    • Set of labels associated with the Registration.
    • the value will be associated with the given key
  • management-settings preferred-renewal-method=lorem
    • 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.
  • renewal-method=sanctus
    • 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.

  • transfer-lock-state=nonumy

    • Controls whether the domain can be transferred to another registrar.

  • .. name=rebum.

    • Output only. Name of the Registration resource, in the format projects/*/locations/*/registrations/.
  • pending-contact-settings.admin-contact email=tempor
    • Required. Email address of the contact.
  • fax-number=dolore
    • Fax number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • phone-number=eos
    • Required. Phone number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • postal-address address-lines=amet.
    • 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 (e.g. "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). 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).
    • Each invocation of this argument appends the given value to the array.
  • administrative-area=dolore
    • 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. Specifically, for Spain this is the province and not the autonomous community (e.g. "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. E.g. in Switzerland this should be left unpopulated.
  • language-code=amet
    • 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=ut
    • Optional. Generally refers to the city/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.
  • organization=at
    • Optional. The name of the organization at the address.
  • postal-code=sit
    • 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 (e.g. state/zip validation in the U.S.A.).
  • recipients=vero
    • Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
    • Each invocation of this argument appends the given value to the array.
  • region-code=duo
    • 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.
  • revision=56
    • 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.
  • sorting-code=ut
    • 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 (e.g. "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).

  • sublocality=rebum.

    • Optional. Sublocality of the address. For example, this can be neighborhoods, boroughs, districts.

  • ... privacy=duo

    • Required. Privacy setting for the contacts associated with the Registration.
  • registrant-contact email=kasd
    • Required. Email address of the contact.
  • fax-number=sadipscing
    • Fax number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • phone-number=tempor
    • Required. Phone number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • postal-address address-lines=sea
    • 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 (e.g. "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). 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).
    • Each invocation of this argument appends the given value to the array.
  • administrative-area=et
    • 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. Specifically, for Spain this is the province and not the autonomous community (e.g. "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. E.g. in Switzerland this should be left unpopulated.
  • language-code=lorem
    • 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=magna
    • Optional. Generally refers to the city/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.
  • organization=takimata
    • Optional. The name of the organization at the address.
  • postal-code=rebum.
    • 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 (e.g. state/zip validation in the U.S.A.).
  • recipients=at
    • Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
    • Each invocation of this argument appends the given value to the array.
  • region-code=invidunt
    • 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.
  • revision=87
    • 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.
  • sorting-code=stet
    • 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 (e.g. "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).

  • sublocality=aliquyam

    • Optional. Sublocality of the address. For example, this can be neighborhoods, boroughs, districts.

  • ...technical-contact email=ut

    • Required. Email address of the contact.
  • fax-number=sit
    • Fax number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • phone-number=vero
    • Required. Phone number of the contact in international format. For example, &#34;+1-800-555-0123&#34;.
  • postal-address address-lines=rebum.
    • 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 (e.g. "Austin, TX"), it is important that the line order is clear. The order of address lines should be "envelope order" for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. "ja" for large-to-small ordering and "ja-Latn" or "en" for small-to-large). 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).
    • Each invocation of this argument appends the given value to the array.
  • administrative-area=dolores
    • 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. Specifically, for Spain this is the province and not the autonomous community (e.g. "Barcelona" and not "Catalonia"). Many countries don't use an administrative area in postal addresses. E.g. in Switzerland this should be left unpopulated.
  • language-code=consetetur
    • 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=dolores
    • Optional. Generally refers to the city/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.
  • organization=sed
    • Optional. The name of the organization at the address.
  • postal-code=invidunt
    • 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 (e.g. state/zip validation in the U.S.A.).
  • recipients=clita
    • Optional. The recipient at the address. This field may, under certain circumstances, contain multiline information. For example, it might contain "care of" information.
    • Each invocation of this argument appends the given value to the array.
  • region-code=dolor
    • 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.
  • revision=19
    • 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.
  • sorting-code=magna
    • 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 (e.g. "CEDEX 7"), or just a number alone, representing the "sector code" (Jamaica), "delivery area indicator" (Malawi) or "post office indicator" (e.g. Côte d'Ivoire).

  • sublocality=diam

    • Optional. Sublocality of the address. For example, this can be neighborhoods, boroughs, districts.

  • .... register-failure-reason=nonumy

    • Output only. The reason the domain registration failed. Only set for domains in REGISTRATION_FAILED state.
  • state=et
    • Output only. The state of the Registration
  • supported-privacy=sanctus
    • Output only. Set of options for the contact_settings.privacy field that this Registration supports.
    • Each invocation of this argument appends the given value to the array.

  • transfer-failure-reason=accusam

    • Output only. Deprecated: For more information, see Cloud Domains feature deprecation. The reason the domain transfer failed. Only set for domains in TRANSFER_FAILED state.

  • .. validate-only=true

    • When true, only validation is performed, without actually registering the domain. Follows: https://cloud.google.com/apis/design/design_patterns#request_validation
  • yearly-price currency-code=sed
    • The three-letter currency code defined in ISO 4217.
  • nanos=94
    • Number of nano (10^-9) units of the amount. The value must be between -999,999,999 and +999,999,999 inclusive. If units is positive, nanos must be positive or zero. If units is zero, nanos can be positive, zero, or negative. If units is negative, nanos must be negative or zero. For example $-1.75 is represented as units=-1 and nanos=-750,000,000.
  • units=takimata
    • The whole units of the amount. For example if currencyCode is &#34;USD&#34;, then 1 unit is one US dollar.

About Cursors

The cursor position is key to comfortably set complex nested structures. The following rules apply:

  • The cursor position is always set relative to the current one, unless the field name starts with the . character. Fields can be nested such as in -r f.s.o .
  • The cursor position is set relative to the top-level structure if it starts with ., e.g. -r .s.s
  • You can also set nested fields without setting the cursor explicitly. For example, to set a value relative to the current cursor position, you would specify -r struct.sub_struct=bar.
  • You can move the cursor one level up by using ... Each additional . moves it up one additional level. E.g. ... would go three levels up.

Optional Output Flags

The method's return value a JSON encoded structure, which will be written to standard output by default.

  • -o out
    • out specifies the destination to which to write the server's result to. It will be a JSON-encoded structure. The destination may be - to indicate standard output, or a filepath that is to contain the received bytes. If unset, it defaults to standard output.

Optional General Properties

The following properties can configure any call, and are not specific to this method.

  • -p $-xgafv=string

    • V1 error format.

  • -p access-token=string

    • OAuth access token.

  • -p alt=string

    • Data format for response.

  • -p callback=string

    • JSONP

  • -p fields=string

    • Selector specifying which fields to include in a partial response.

  • -p key=string

    • API key. Your API key identifies your project and provides you with API access, quota, and reports. Required unless you provide an OAuth 2.0 token.

  • -p oauth-token=string

    • OAuth 2.0 token for the current user.

  • -p pretty-print=boolean

    • Returns response with indentations and line breaks.

  • -p quota-user=string

    • Available to use for quota purposes for server-side applications. Can be any arbitrary string assigned to a user, but should not exceed 40 characters.

  • -p upload-type=string

    • Legacy upload protocol for media (e.g. "media", "multipart").

  • -p upload-protocol=string

    • Upload protocol for media (e.g. "raw", "multipart").