# Get user notifications

Returns a paginated list of notifications for the authenticated user.
Notifications are returned in descending order by creation timestamp (most recent first).
Supports cursor-based pagination via the cursor query parameter.

Endpoint: GET /me/notifications
Version: 0.1.0
Security: bearerAuth

## Query parameters:

  - `limit` (integer)
    Maximum number of notifications to return (default: 50, max: 100)
    Example: 50

  - `cursor` (string)
    ISO timestamp cursor for pagination (exclusive, returns notifications created before this timestamp)
    Example: "2024-01-01T12:00:00Z"

## Response 200 fields (application/json):

  - `notifications` (array, required)
    List of notifications (most recent first)

  - `notifications.id` (string, required)
    Unique identifier for the notification
    Example: "notification_123"

  - `notifications.title` (string, required)
    Notification title
    Example: "Earnings Blocked"

  - `notifications.body` (string, required)
    Notification body message
    Example: "Your earnings of $10.00 for submission submission_abc were blocked due to insufficient campaign escrow."

  - `notifications.severity` (string, required)
    Notification severity level:
- NOTIFICATION_SEVERITY_INFO: Informational notification
- NOTIFICATION_SEVERITY_WARNING: Warning notification requiring attention
- NOTIFICATION_SEVERITY_ERROR: Error notification indicating a problem
    Enum: "NOTIFICATION_SEVERITY_INFO", "NOTIFICATION_SEVERITY_WARNING", "NOTIFICATION_SEVERITY_ERROR"

  - `notifications.reason_code` (string,null, required)
    Machine-readable reason code for the notification (e.g., INSUFFICIENT_ESCROW)
    Example: "INSUFFICIENT_ESCROW"

  - `notifications.entity_ref` (object,null, required)
    Reference to the entity that triggered this notification
    Example: {"type":"ACCURUAL","id":"accrual_xyz"}

  - `notifications.entity_ref.type` (string)
    Type of entity referenced
    Enum: "CAMPAIGN", "ACCURUAL", "PARTICIPATION", "SOCIAL_ACCOUNT"

  - `notifications.entity_ref.id` (string)
    Unique identifier of the referenced entity
    Example: "accrual_xyz"

  - `notifications.is_read` (boolean, required)
    Whether the notification has been read by the user

  - `notifications.read_at` (string,null, required)
    ISO timestamp when the notification was marked as read (null if unread)

  - `notifications.created_at` (string, required)
    ISO timestamp when the notification was created
    Example: "2024-01-01T12:00:00Z"

  - `next_cursor` (string,null, required)
    ISO timestamp cursor for pagination. Use this value as the cursor query parameter
in the next request to fetch older notifications. Null if there are no more notifications.

## Response 400 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 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 500 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"