# Sinch Compliance API - Brands

This API describes the set of endpoints available to create customer brands.

The list of endpoints allows to create, update and delete a customer brand and also get the current state.

Version: 1.0.0
License: MIT

## Servers

Production server. Data processed and stored within Europe.
```
https://compliance.api.sinch.com
```

## Security

### OAuth2

The username and password are your Key ID and Key Secret from the Access keys section in the Sinch Customer Dashboard. Exchange these for a bearer token (access token).

Type: oauth2

### hmacAuth

HMAC-SHA256 signature used to authenticate webhook deliveries. The signature is computed over the request body using the project's HMAC secret and sent in the X-Sinch-Signature header. Please refer to the Brand Callback endpoints for more information.

Type: apiKey
In: header
Name: X-Sinch-Signature

## Download OpenAPI description

[Sinch Compliance API - Brands](https://developers.sinch.com/_bundle/docs/compliance-center/api-reference/compliance-brands.yaml)

## Brands

Create and manage Customer Brands

### Creates a new Draft Brand in US with the request data.

 - [POST /v1/projects/{projectId}/us/brands](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brands/createbrand.md): Creates a new Draft Brand in US with the request data.

Note: The Idempotency-Key header is not supported in this version. Submitting the same request twice may create duplicate resources. Callers are responsible for deduplicating on their end. Idempotency-Key support will be added when this operation reaches Stable stability.

### List brands for a project

 - [GET /v1/projects/{projectId}/us/brands](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brands/listbrands.md): List existing brands according to the specified filters.

### Imports an existing Brand in US.

 - [POST /v1/projects/{projectId}/us/brands/import](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brands/importbrand.md): 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.

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

 - [GET /v1/projects/{projectId}/us/brands/{brandId}](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brands/getbrand.md): The endpoint receives as path param project id and brand id. If the project and brand exist, the details of the brand are returned.

### Delete a brand by project and brand id.

 - [DELETE /v1/projects/{projectId}/us/brands/{brandId}](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brands/deletebrand.md): The endpoint receives as path param project id and brand id. If the project and brand exist, the brand is deleted.

### Patches an existing Brand in US with the request data.

 - [PATCH /v1/projects/{projectId}/us/brands/{brandId}](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brands/patchbrand.md): Patches an existing brand. Fields omitted from the request body are unchanged. Fields set to null are treated as an explicit request to clear the field; if a field does not support clearing, the request will fail with 400.

### Uploads an attachment to be linked to a brand. The attachment will be automatically assigned to the new Brand Orders when needed.

 - [POST /v1/projects/{projectId}/us/brands/{brandId}/attachments](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brands/uploadbrandattachment.md): Upload an attachment to be linked to a brand.

### Download brand attachment

 - [GET /v1/projects/{projectId}/us/brands/{brandId}/attachments/{attachmentId}](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brands/downloadbrandattachment.md): Download Brand Attachment.

### Delete Brand Attachment

 - [DELETE /v1/projects/{projectId}/us/brands/{brandId}/attachments/{attachmentId}](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brands/deletebrandattachment.md): Delete a Brand attachment.

## Orders

Create and manage Customer Brand Orders

### List Brand Orders according to the filters applied.

 - [GET /v1/projects/{projectId}/us/orders](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/orders/listbrandorders.md): List Brand Orders, according to the filters applied. This endpoint allows filtering over all brands.

### Creates a new Brand Order for the specified process.

 - [POST /v1/projects/{projectId}/us/brands/{brandId}/orders](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/orders/createbrandorder.md): Creates a new Brand Order for the specified brand ID and process selected.

Note: The Idempotency-Key header is not supported in this version. Submitting the same request twice may create duplicate orders. Callers are responsible for deduplicating on their end. Idempotency-Key support will be added when this operation reaches Stable stability.

### List Brand Orders by Brand Id according to the filters applied.

 - [GET /v1/projects/{projectId}/us/brands/{brandId}/orders](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/orders/listbrandorderbybrandid.md): List Brand Orders per brand id, according to the filters applied.

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

 - [GET /v1/projects/{projectId}/us/brands/{brandId}/orders/{orderId}](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/orders/getbrandorder.md): 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.

### Delete Brand Order

 - [DELETE /v1/projects/{projectId}/us/brands/{brandId}/orders/{orderId}](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/orders/deletebrandorder.md): Delete a Brand Order.

### Updates a Brand Order.

 - [POST /v1/projects/{projectId}/us/brands/{brandId}/orders/{orderId}/retry](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/orders/retrybrandorder.md): Updates a brand Order. Only INCOMPLETE or NEW orders can be retried. Retry flow will get new properties and attachments from the brand and apply the same validations as create Order. No body is needed.

### resendConfirmationEmail request for Brand Order.

 - [POST /v1/projects/{projectId}/us/brands/{brandId}/orders/{orderId}/resendConfirmationEmail](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/orders/brandorderresendconfirmationemail.md): Resends the brand registration confirmation email to the end-customer. Certain product verification processes require the end-customer's approval via email to complete a brand's registration for a specific use case. If the end-customer has lost or did not receive the original email, you can call this endpoint to trigger a resend, enabling them to finalize the registration process.

This action can only be requested if the order is in a PENDING state. Furthermore, this functionality is currently available only for 10DLC/RCS (TCR) registration processes.

### Verify OTP code for TCR Sole Proprietor verification

 - [POST /v1/projects/{projectId}/us/brands/{brandId}/orders/{orderId}/verifyOtp](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/orders/brandorderverifyotp.md): 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.

### Resend OTP for TCR Sole Proprietor verification

 - [POST /v1/projects/{projectId}/us/brands/{brandId}/orders/{orderId}/resendOtp](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/orders/brandorderresendotp.md): This endpoint triggers a resend of the One-Time Password (OTP) required for verifying US_10DLC_TCR_SOLE_PROPRIETOR orders. Use this if the initial OTP expired or was not received by the brand. The new OTP will be sent to the brand's registered mobilePhoneNumber.

Important Requirement: Just like the initial request, the brand's mobilePhoneNumber must be a valid United States (US) or Canadian (CA) phone number.

## Brand Webhooks

Brand Webhook events.

### Callback for brand order status update

 - [POST BrandOrderStatusUpdated](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brand-webhooks-delivery/brandorderstatuscallback.md): The endpoint receives a callback when the brand order status is updated. To receive callback notifications, the customer must provide a callback URL in the create Order (/us/brands/{brandId}/orders) request body or when importing (/us/brands/import) a brand. The callback URL must be a valid URL and must be reachable from Sinch. Read brands callback configuration documentation for more details.

## Brand Callbacks

You can set up callback URLs to receive event notifications when your brand status is updated.
When delivering events the order is not guaranteed (for example, a failed event scheduled for retry will not block other events that were queued).
The client's callback handler must implement the state machine that can decide what to do with unexpected events, for example, "old" events or invalid state transitions. In these cases the handler could use the API to GET the latest state for the resource.
The callback handler is expected to "ingest" the event and respond with 200 OK. The domain-specific business logic and processes should be executed outside of the callback request, as internal asynchronous jobs.
An HMAC encrypted secret is used for hashing the payload and sending the hashed String via the X-Sinch-Signature header - that you can use to validate that an incoming request is secure. Hmac secret value can be checked with GET endpoint, and it can be updated with PUT endpoint

### Get a callback configuration by project id.

 - [GET /v1/projects/{projectId}/callbackConfig](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brand-callbacks/getcallbackconfig.md): Returns the callback configuration for the specified project. The HMAC secret is masked —
only the last 6 characters are visible. To retrieve the full secret, rotate it using
POST /v1/projects/{projectId}/callbackConfig/rotate or set a new one via PATCH.

### Set a customer-provided HMAC secret for webhook signing.

 - [PATCH /v1/projects/{projectId}/callbackConfig](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brand-callbacks/updatecallbackconfig.md): Sets a customer-provided HMAC secret for the specified project. The full secret is returned
once in the response body — this is the only time it is visible in plain text. Store it
securely immediately after this call.

### Rotate the HMAC secret for webhook signing.

 - [POST /v1/projects/{projectId}/callbackConfig/rotate](https://developers.sinch.com/docs/compliance-center/api-reference/compliance-brands/brand-callbacks/rotatecallbacksecret.md): Generates a new server-side HMAC secret for the specified project and replaces the
existing one. The full secret is returned once in the response body — this is the only
time it is visible in plain text. Store it securely immediately after this call.

Use this endpoint when you want Sinch to generate a cryptographically random secret
rather than supplying your own.

