# Verify OTP code for 10DLC Sole Proprietor verification

Verifies the One-Time Password (OTP) received by the brand's registered mobile phone number to complete the US_10DLC_TCR_SOLE_PROPRIETOR order. After creating the order, an OTP is automatically sent via SMS to the mobilePhoneNumber associated with the brand. Submit the OTP code using this endpoint to finalise the registration.
Important Requirement: To successfully receive the OTP, the brand's mobilePhoneNumber must be a valid United States (US) or Canadian (CA) phone number.

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

## Security:

  - `OAuth2` (unknown)
    oauth2 scopes: write

## Path parameters:

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

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

  - `orderId` (string, required)
    Order ID

## Request body:

  - `application/json` (unknown)
    OTP received in the mobilePhoneNumber after creating the brand order.

## Request fields (application/json):

  - `otp` (string, required)
    OTP code received in the mobilePhoneNumber.

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