# Rotate the HMAC secret for webhook signing.

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.

Endpoint: POST /v1/projects/{projectId}/callbackConfig/rotate
Version: 1.0.0
Security: OAuth2

## Security:

  - `OAuth2` (unknown)
    oauth2 scopes: write

## Path parameters:

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

## Response 200:

  - `200` (unknown)
    New secret generated. The full secret is returned once — store it securely.

## Response 200 fields (application/json):

  - `projectId` (string)
    Project ID this callback configuration belongs to.

  - `hmacSecret` (string)
    The full HMAC secret for webhook signature verification. Returned only once — on creation or rotation.

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