Skip to main content

API Overview

The User Service exposes RESTful endpoints for managing users and their email addresses. All endpoints require authentication via Cognito JWT tokens. Base URL: https://api.example.com/v1

User Endpoints

Get Current User

Retrieve the authenticated user’s profile.
Returns the current user’s profile data.
Response:

Update Current User

Update the authenticated user’s profile.
Updates profile fields. Partial updates supported.
Request:
Response:

Delete Current User

Soft-delete the authenticated user’s account.
Sets user status to deleted. Does not remove data.
Response:
Soft delete is used to maintain referential integrity. Downstream services receive a user.deleted event to handle cleanup (cancel pending bookings, final invoices, etc.).

Email Endpoints

List User Emails

Get all email addresses for the current user.
Returns all emails associated with the user.
Response:

Add Email

Add a new email address to the user’s account.
Adds a new email. Verification required before use.
Request:
Response:

Delete Email

Remove an email address from the user’s account.
Removes the specified email.

Request Verification

Send a verification code to an unverified email.
Sends verification code. Rate limited.
Response:

Confirm Verification

Confirm email ownership with verification code.
Confirms the verification code.
Request:

Set Primary Email

Set an email as the user’s primary email address.
Designates this email as primary.

Edge Cases

Cannot Delete Primary Email

Scenario: User tries to delete their primary email. Handling:
Why: Primary email is used for account recovery and critical notifications. User must explicitly choose a replacement.

Cannot Delete Last Email

Scenario: User tries to delete their only email address. Handling:
Why: Email is required for account recovery. Deleting all emails would orphan the account.

Duplicate Email

Scenario: User tries to add an email that’s already in use (by them or another user). Handling:
Why: Generic message prevents email enumeration attacks.

Unverified Email as Primary

Scenario: User tries to set an unverified email as primary. Handling:
Why: Primary email is used for critical account functions. Ownership must be confirmed.

Verification Rate Limiting

Scenario: User requests too many verification codes. Handling:
Limits:
  • 3 verification requests per email per hour
  • 5 confirmation attempts per code

Rate Limiting Implementation

Rate limiting in a serverless context requires stateful tracking. Here’s how to implement it.

Strategy: DynamoDB Token Bucket

DynamoDB is used to track request counts per user/email with TTL for automatic cleanup. Rate Limit Table Schema: Implementation:
Usage in handler:

Alternative: API Gateway Usage Plans

For API-wide rate limiting (not user-specific):

Rate Limit Headers

All rate-limited endpoints return standard headers:

Concurrent Update Conflict

Scenario: Two requests update the same user simultaneously. Handling:
Implementation: Optimistic locking with version number. Second request fails condition check.

Request Validation

Email Format

Phone Format

Name Fields


Error Response Format

All errors follow a consistent format:
The requestId enables correlation with CloudWatch logs for debugging.