---
title: "Callback for brand order status update"
method: POST
path: "BrandOrderStatusUpdated"
tags: ["brand-webhooks-delivery"]
---

# Callback for brand order status update

`POST BrandOrderStatusUpdated` (webhook)

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.

## Payload

- CallbackBrandOrderStatusUpdatedBody — Base fields required by the CloudEvents spec v1.0 (https://cloudevents.io). All Sinch webhook payloads conform to this structure.
  - `specversion` '1.0', required — The version of the CloudEvents specification which the event uses. Always "1.0".
  - `id` string, required — Unique identifier for the event within the scope of the source. Clients MUST treat events with the same source+id as duplicates.
  - `source` string, uri, required — URI-reference identifying the context in which the event occurred. Combined with id, this MUST be globally unique per event.
  - `type` string, required — Reverse-DNS-prefixed event type string. The last component identifies the event version (e.g. com.sinch.registrations.brand.order.v1.BrandOrderStatusUpdate).
  - `time` string, date-time, required — Timestamp of when the event was produced, in RFC-3339 format with timezone.
  - `data` BrandOrderEventData — Business payload carried in the `data` property of a brand order CloudEvent. Contains the brand order status update details that triggered the event.
    - `projectId` string — The ID of the project to which the event belongs.
    - `resourceId` string — Corresponds to the order id the event belongs to.
    - `resourceType` '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' — 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.
    - `status` 'NEW' | 'PENDING' | 'PENDING_REVIEW' | 'REJECTED' | 'INCOMPLETE' | 'COMPLETED' | 'ARCHIVED' — 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.
    - `comments` string — Comments related to the brand order status update. For instance, an incomplete brand order status update can include the reason why the brand order is incomplete, or the fields that must be updated.

## Acknowledgement `200`

OK

---

[API](https://skmtc.net/sinch/apis/sinch-compliance-api-brands.md) · [All operations](https://skmtc.net/sinch/apis/sinch-compliance-api-brands/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/sinch/sinch-compliance-api-brands/revisions/fcc788f31a0a/schema)