# Get TikTok connection status

Returns the current TikTok connection status and capabilities for the authenticated user.
Returns 404 if no connection exists. The response includes verification status,
available capabilities, and any error codes.

Endpoint: GET /me/tiktok-connection
Version: 0.1.0
Security: bearerAuth

## Response 200 fields (application/json):

  - `tiktok_open_id` (string,null, required)
    TikTok open ID for the connected account
    Example: "open_id_12345"

  - `status` (string, required)
    Current verification status of the TikTok connection:
- PENDING: Connection created but not yet verified
- VALID: Connection verified with full capabilities
- LIMITED: Connection verified but with limited capabilities
- ERROR: Connection verification failed
    Enum: "PENDING", "VALID", "LIMITED", "ERROR"

  - `capabilities` (object, required)

  - `capabilities.can_read_profile` (boolean, required)
    Whether the connection can read TikTok profile data
    Example: true

  - `capabilities.can_list_videos` (boolean, required)
    Whether the connection can list TikTok videos
    Example: true

  - `capabilities.can_read_video_metrics` (boolean, required)
    Whether the connection can read TikTok video metrics
    Example: true

  - `reason_code` (string,null, required)
    Machine-readable reason code for current status
    Example: "VERIFICATION_OK"

  - `reason_message` (string,null, required)
    Human-readable reason message
    Example: "Connection verified successfully"

  - `last_verified_at` (string,null, required)
    ISO 8601 timestamp of the last verification attempt
    Example: "2024-01-01T12:00:00Z"

  - `last_error_code` (string,null, required)
    Error code from the last verification attempt (if any)

  - `last_error_message` (string,null, required)
    Error message from the last verification attempt (if any)

  - `created_at` (string, required)
    ISO 8601 timestamp when the connection was created
    Example: "2024-01-01T10:00:00Z"

  - `updated_at` (string, required)
    ISO 8601 timestamp when the connection was last updated
    Example: "2024-01-01T12:00:00Z"

## Response 401 fields (application/json):

  - `error` (string, required)
    Error code that identifies the type of error. This is a stable identifier that can be used
for programmatic error handling. Common codes include:
- NOT_FOUND - Resource not found
- VALIDATION_ERROR - Input validation failed
- PERMISSION_DENIED - User lacks permission for the action
- CONFLICT - Request conflicts with current resource state
- UNAUTHORIZED - Authentication required
- INTERNAL_SERVER_ERROR - Unexpected server error
    Example: "VALIDATION_ERROR"

  - `message` (string, required)
    User-friendly error message that should always be displayed to end users. This message is
designed to be clear, actionable, and free of technical details.

This field is always present and contains the primary message for end users.
    Example: "The email address you entered is not valid. Please check the format and try again."

  - `technicalMessage` (string)
    Optional technical message for developers. Contains detailed information including IDs,
error codes, and technical context. Only included when it differs from the user-friendly
message field. When present, developers can use this for debugging while end users
should see the message field.
    Example: "Campaign with ID campaign_123 not found"

  - `details` (object)
    Additional error details (optional). May contain structured information about the error,
such as validation field errors or additional context.

  - `requestId` (string)
    Unique request identifier for tracing. Included in X-Request-ID header and can be used
to correlate errors with server logs.
    Example: "550e8400-e29b-41d4-a716-446655440000"

  - `timestamp` (string, required)
    ISO 8601 timestamp when the error occurred
    Example: "2024-01-01T00:00:00Z"

## Response 404 fields (application/json):

  - `error` (string, required)
    Error code that identifies the type of error. This is a stable identifier that can be used
for programmatic error handling. Common codes include:
- NOT_FOUND - Resource not found
- VALIDATION_ERROR - Input validation failed
- PERMISSION_DENIED - User lacks permission for the action
- CONFLICT - Request conflicts with current resource state
- UNAUTHORIZED - Authentication required
- INTERNAL_SERVER_ERROR - Unexpected server error
    Example: "VALIDATION_ERROR"

  - `message` (string, required)
    User-friendly error message that should always be displayed to end users. This message is
designed to be clear, actionable, and free of technical details.

This field is always present and contains the primary message for end users.
    Example: "The email address you entered is not valid. Please check the format and try again."

  - `technicalMessage` (string)
    Optional technical message for developers. Contains detailed information including IDs,
error codes, and technical context. Only included when it differs from the user-friendly
message field. When present, developers can use this for debugging while end users
should see the message field.
    Example: "Campaign with ID campaign_123 not found"

  - `details` (object)
    Additional error details (optional). May contain structured information about the error,
such as validation field errors or additional context.

  - `requestId` (string)
    Unique request identifier for tracing. Included in X-Request-ID header and can be used
to correlate errors with server logs.
    Example: "550e8400-e29b-41d4-a716-446655440000"

  - `timestamp` (string, required)
    ISO 8601 timestamp when the error occurred
    Example: "2024-01-01T00:00:00Z"

## Response 503 fields (application/json):

  - `error` (string, required)
    Error code that identifies the type of error. This is a stable identifier that can be used
for programmatic error handling. Common codes include:
- NOT_FOUND - Resource not found
- VALIDATION_ERROR - Input validation failed
- PERMISSION_DENIED - User lacks permission for the action
- CONFLICT - Request conflicts with current resource state
- UNAUTHORIZED - Authentication required
- INTERNAL_SERVER_ERROR - Unexpected server error
    Example: "VALIDATION_ERROR"

  - `message` (string, required)
    User-friendly error message that should always be displayed to end users. This message is
designed to be clear, actionable, and free of technical details.

This field is always present and contains the primary message for end users.
    Example: "The email address you entered is not valid. Please check the format and try again."

  - `technicalMessage` (string)
    Optional technical message for developers. Contains detailed information including IDs,
error codes, and technical context. Only included when it differs from the user-friendly
message field. When present, developers can use this for debugging while end users
should see the message field.
    Example: "Campaign with ID campaign_123 not found"

  - `details` (object)
    Additional error details (optional). May contain structured information about the error,
such as validation field errors or additional context.

  - `requestId` (string)
    Unique request identifier for tracing. Included in X-Request-ID header and can be used
to correlate errors with server logs.
    Example: "550e8400-e29b-41d4-a716-446655440000"

  - `timestamp` (string, required)
    ISO 8601 timestamp when the error occurred
    Example: "2024-01-01T00:00:00Z"