# Get a brand order by project id, brand id and order id.

The endpoint receives as path param project id, brand id and order id. If the project and order exist, the details of the brand are returned.

Endpoint: GET /v1/projects/{projectId}/us/brands/{brandId}/orders/{orderId}
Version: 1.0.0
Security: OAuth2

## Security:

  - `OAuth2` (unknown)
    oauth2 scopes: read

## Path parameters:

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

  - `brandId` (string, required)
    Brand ID reference

  - `orderId` (string, required)
    Order id

## Response 200:

  - `200` (unknown)
    OK

## Response 200 fields (application/json):

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

  - `brandId` (string)
    Brand ID this Order belongs to.

  - `status` (string)
    Brand order status represents the current state of the brand order in the system. When a brand order is created, it is in NEW status. After that, it can be moved to PENDING status when the validation process starts, then it can be moved to REJECTED or INCOMPLETE if the validation process fails, or to COMPLETED if the validation process is successful. When a brand order is in INCOMPLETE status, customer can update the brand/brand order. Updating the brand order moves the brand order to PENDING_REVIEW state, what means that is waiting for another review after the customer changes. Finally, a brand order can be moved to ARCHIVED status after a cancellation.
    Enum: "NEW", "PENDING", "PENDING_REVIEW", "REJECTED", "INCOMPLETE", "COMPLETED", "ARCHIVED"

  - `metadataName` (string)
    These are the different processes the customers can request to add different channels to the Brand.
**Note:** US_SC_REGISTRY is only used to retrieve existing brand orders. It cannot be used for new ones.
    Enum: "US_SC_REGISTRY", "US_SC_GCH", "US_SC_GCH_CONTENT_PROVIDER", "US_10DLC_TCR_PRIVATE_BRAND_REGISTRATION", "US_10DLC_TCR_PUBLIC_BRAND_REGISTRATION", "US_10DLC_TCR_PRIVATE_BRAND_UPDATE", "US_10DLC_TCR_PUBLIC_BRAND_UPDATE", "US_10DLC_TCR_PRIVATE_MOCK", "US_10DLC_TCR_PUBLIC_MOCK", "US_10DLC_TCR_SOLE_PROPRIETOR", "US_10DLC_TCR_PRIVATE_STANDARD_BRAND_REGISTRATION", "US_10DLC_TCR_PRIVATE_ENHANCED_BRAND_REGISTRATION", "US_10DLC_TCR_PUBLIC_STANDARD_BRAND_REGISTRATION", "US_10DLC_TCR_PUBLIC_ENHANCED_BRAND_REGISTRATION", "US_RCS_TCR_PRIVATE_BRAND_REGISTRATION", "US_RCS_TCR_PUBLIC_BRAND_REGISTRATION", "US_RCS_TCR_UPDATE_ASSETS"

  - `logs` (array)
    Detailed history of the status changes this brand went through

  - `logs.createTime` (string)
    Create time of this log entry. ISO date time format in UTC.

  - `logs.message` (string)
    Optional message with details of the brand status update or new channel added. It can contain information provided by the agent handling the request.

  - `channels` (array)
    Channels available for this Brand Order

  - `thirdPartyMetadata` (array)
    Third party metadata available for this Brand Order

  - `thirdPartyMetadata.name` (string)
    Third Party metadata property name.

  - `thirdPartyMetadata.value` (string)
    Third party metadata property value.

  - `pricing` (object)
    Money amount with currency.

  - `pricing.amount` (string)
    The amount of money.

  - `pricing.currencyCode` (string)
    The currency of the money amount, in ISO 4217 format.

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

  - `createTime` (string)
    Create time of the request. ISO date time format in UTC.

  - `updateTime` (string)
    Update time of the request. ISO date time format in UTC.

## 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 or order 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.