# Imports an existing Brand in US.

This endpoint allows you to import a brand that has already been registered through another reseller or directly by the end-customer, enabling you to manage it through your account. To initiate the transfer, you must specify one of the available import options (IMPORT_TCR_BRAND or IMPORT_GCH_BRAND) and provide the brand's unique ID from its original registry.
Upon receiving the request, the system will copy the brand's information from the source and create an import order that includes all existing third-party metadata from the original registration. Depending on the brand's original registry, an email will be sent to the brand's registered contact address to approve or deny the import request.
Please note that an imported brand cannot be directly modified or updated through our system. For example, a brand imported via IMPORT_GCH_BRAND cannot have its Short Code registration details changed, although it can be extended for other services like 10DLC if required. All maintenance and update operations for the brand remain the responsibility of the original register.

Endpoint: POST /v1/projects/{projectId}/us/brands/import
Version: 1.0.0
Security: OAuth2

## Security:

  - `OAuth2` (unknown)
    oauth2 scopes: write

## Path parameters:

  - `projectId` (string, required)
    Customer's project id

## Request body:

  - `application/json` (unknown)
    Import Brand request body. It includes the import option to be used and the unique identifier of the brand in its original registry. Depending on the import option selected, the required identifier will differ, for IMPORT_TCR_BRAND, the required identifier is the 10DLC Brand ID; for IMPORT_GCH_BRAND, the required identifier is the US Short Code Registry Account ID.

## Request fields (application/json):

  - `displayName` (string, required)
    The name of the brand. DisplayName must be unique per projectId and marketCode (US)

  - `importType` (string, required)
    Type of import, options are IMPORT_TCR_BRAND for 10DLC / RCS and IMPORT_GCH_BRAND for Short Code
    Enum: "IMPORT_TCR_BRAND", "IMPORT_GCH_BRAND"

  - `externalBrandId` (string, required)
    The external brand ID obtained in the original order. It can be the 10DLC brand Id or the US Short Code Registry brand Id.

  - `callbackUrl` (string)
    The URL to receive the order status update callback. The URL must be a valid URL and must be reachable from Sinch.

## Response 201:

  - `201` (unknown)
    Brand import initiated successfully.

## Response 201 fields (application/json):

  - `brandId` (string)
    The unique identifier for the brand.

  - `brandOrderId` (string)
    The unique identifier for the brand order.

  - `brandOwnerContactEmail` (string)
    The email of the brand owner contact provided in the original order, masked for privacy reasons. This field is included for informational purposes, but it is not intended for communication as the email is masked.

## Response 400:

  - `400` (unknown)
    BAD_REQUEST: Any validation error

## Response 400 fields (application/problem+json):

  - `type` (string, required)
    A URI reference that identifies the problem type. This URI reference should provide a human-readable explanation of the problem type when dereferenced.

  - `title` (string, required)
    A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for localization purposes.

  - `errors` (array)
    Detailed information about the error. This field can contain multiple error details to provide more context about the error that occurred.

  - `errors.pointer` (string)
    JSON pointer to the field that caused the error, following RFC 6901.

  - `errors.detail` (string)
    A human-readable explanation specific to this occurrence of the problem. Like title, this field is not intended for end users, but rather for developers to understand the details of the error that occurred.

  - `detail` (string)
    A human-readable explanation of the error that occurred.

## Response 401:

  - `401` (unknown)
    UNAUTHENTICATED: Missing or invalid authentication credentials.

## Response 401 fields (application/problem+json):

  - `type` (string, required)
    A URI reference that identifies the problem type. This URI reference should provide a human-readable explanation of the problem type when dereferenced.

  - `title` (string, required)
    A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for localization purposes.

  - `errors` (array)
    Detailed information about the error. This field can contain multiple error details to provide more context about the error that occurred.

  - `errors.pointer` (string)
    JSON pointer to the field that caused the error, following RFC 6901.

  - `errors.detail` (string)
    A human-readable explanation specific to this occurrence of the problem. Like title, this field is not intended for end users, but rather for developers to understand the details of the error that occurred.

  - `detail` (string)
    A human-readable explanation of the error that occurred.

## Response 401 headers (application/problem+json):

  - `WWW-Authenticate` (string)
    Authentication challenge per RFC 7235.

## Response 403:

  - `403` (unknown)
    PERMISSION_DENIED: The authenticated user does not have permission to perform this operation.

## Response 403 fields (application/problem+json):

  - `type` (string, required)
    A URI reference that identifies the problem type. This URI reference should provide a human-readable explanation of the problem type when dereferenced.

  - `title` (string, required)
    A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for localization purposes.

  - `errors` (array)
    Detailed information about the error. This field can contain multiple error details to provide more context about the error that occurred.

  - `errors.pointer` (string)
    JSON pointer to the field that caused the error, following RFC 6901.

  - `errors.detail` (string)
    A human-readable explanation specific to this occurrence of the problem. Like title, this field is not intended for end users, but rather for developers to understand the details of the error that occurred.

  - `detail` (string)
    A human-readable explanation of the error that occurred.

## Response 404:

  - `404` (unknown)
    NOT_FOUND: The project id introduced does not exist.

## Response 404 fields (application/problem+json):

  - `type` (string, required)
    A URI reference that identifies the problem type. This URI reference should provide a human-readable explanation of the problem type when dereferenced.

  - `title` (string, required)
    A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for localization purposes.

  - `errors` (array)
    Detailed information about the error. This field can contain multiple error details to provide more context about the error that occurred.

  - `errors.pointer` (string)
    JSON pointer to the field that caused the error, following RFC 6901.

  - `errors.detail` (string)
    A human-readable explanation specific to this occurrence of the problem. Like title, this field is not intended for end users, but rather for developers to understand the details of the error that occurred.

  - `detail` (string)
    A human-readable explanation of the error that occurred.

## Response 429:

  - `429` (unknown)
    RESOURCE_EXHAUSTED: Too many requests. The client has exceeded the rate limit.

## Response 429 fields (application/problem+json):

  - `type` (string, required)
    A URI reference that identifies the problem type. This URI reference should provide a human-readable explanation of the problem type when dereferenced.

  - `title` (string, required)
    A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for localization purposes.

  - `errors` (array)
    Detailed information about the error. This field can contain multiple error details to provide more context about the error that occurred.

  - `errors.pointer` (string)
    JSON pointer to the field that caused the error, following RFC 6901.

  - `errors.detail` (string)
    A human-readable explanation specific to this occurrence of the problem. Like title, this field is not intended for end users, but rather for developers to understand the details of the error that occurred.

  - `detail` (string)
    A human-readable explanation of the error that occurred.

## Response 500:

  - `500` (unknown)
    INTERNAL: Internal server error. Typically, a server bug.

## Response 500 fields (application/problem+json):

  - `type` (string, required)
    A URI reference that identifies the problem type. This URI reference should provide a human-readable explanation of the problem type when dereferenced.

  - `title` (string, required)
    A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for localization purposes.

  - `errors` (array)
    Detailed information about the error. This field can contain multiple error details to provide more context about the error that occurred.

  - `errors.pointer` (string)
    JSON pointer to the field that caused the error, following RFC 6901.

  - `errors.detail` (string)
    A human-readable explanation specific to this occurrence of the problem. Like title, this field is not intended for end users, but rather for developers to understand the details of the error that occurred.

  - `detail` (string)
    A human-readable explanation of the error that occurred.