# List Brand Orders according to the filters applied. List Brand Orders, according to the filters applied. This endpoint allows filtering over all brands. Endpoint: GET /v1/projects/{projectId}/us/orders Version: 1.0.0 Security: OAuth2 ## Security: - `OAuth2` (unknown) oauth2 scopes: read ## Path parameters: - `projectId` (string, required) Customer's project id ## Query parameters: - `status` (array) The brand Order status to filter the brand orders. - `metadataName` (string) Filter brand orders by brand registration process metadata name. - `sort` (string) Sorting of the results using SQL-like syntax: comma-separated field names with an optional ':desc' or ':asc' suffix. Fields that support sorting are 'metadataName', 'status', 'createTime', 'updateTime'. Defaults to ascending order when no suffix is provided. - `pageSize` (integer) Size of the page to be returned. Default is 20. Maximum is 100. - `pageToken` (string) Page token to request subsequent pages when using pagination. This should be the value generated by the system in a previous list request. ## Response 200: - `200` (unknown) OK ## Response 200 fields (application/json): - `orders` (array) List of brand orders - `orders.brandOrderId` (string) The unique identifier for the brand order. - `orders.brandId` (string) Brand ID this Order belongs to. - `orders.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" - `orders.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" - `orders.createTime` (string) Create time of the request. ISO date time format in UTC. - `orders.updateTime` (string) Update time of the request. ISO date time format in UTC. - `links` (object) Pagination links. - `links.next` (string) Link to the next page of results, following RFC 8288. Absence of this link indicates the last page. - `meta` (object) Pagination metadata for list responses. - `meta.totalCount` (integer) Total count of resources matching the provided search criteria. This field cannot be null; an empty result will return 0. ## Response 200 headers (application/json): - `Link` (string) Pagination links per RFC 8288. A `rel="next"` link is present when there are more results. Absence of a `next` link indicates the last page. Example: ; rel="next" ## 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.