Architecture

API Structure

The Nomad Media API is built on AWS API Gateway and consists of two distinct APIs:

Admin API — Full administrative functionality: asset management, user management, configuration, processing jobs, and all write operations. Requires admin-level credentials.
Portal API — Public-facing functionality for the Content Portal and the Virtual Experience Platform (VEP). Used for search, asset retrieval, streaming, and end-user operations.

Both APIs use bearer token authentication. See Authentication for details on obtaining tokens.

API Base URLs

Your environment's base URLs are provided during onboarding. They follow a consistent naming pattern:

Admin API: https://admin-app.{CLIENT_DOMAIN}/api
Portal API: https://portal.{CLIENT_DOMAIN}/api

Diagnostics

Diagnostics logging can be enabled on the API by setting the following environment variable on the appropriate Lambda function:

debug = true

This enables verbose logging in CloudWatch for that Lambda, useful during development and troubleshooting.

Infrastructure Overview

The Nomad Media platform runs entirely on AWS. Key infrastructure components include:

Component	Purpose
API Gateway	HTTP routing for Admin and Portal APIs
Lambda	Serverless compute for API handlers, processors, and background workers
DynamoDB	Asset registry and transactional data storage
S3	Primary media and metadata storage with versioning enabled
CloudFront	CDN for media delivery with optional signed cookies for secure access
EventBridge	Event bus for Nomad Media events (asset changes, processing completions)
SQS	Message queue for decoupled background processing
Secrets Manager	Secure credential storage for integrations
CloudWatch	Logging and monitoring for all Lambda functions
CloudTrail	AWS-level audit trail

Logging and Auditing

Nomad Media uses several mechanisms for monitoring, auditing, and debugging:

CloudTrail

CloudTrail is enabled for all AWS API activity within the Nomad Media account. It provides a complete audit trail of infrastructure-level operations.

CloudWatch

Each Lambda function writes to its own CloudWatch log group. The most important log groups for monitoring user activity are:

Log Group	Purpose
`web-api-portal-mainEntryPoint`	All Portal API requests — logins, searches, asset reads
`web-api-admin-mainEntryPoint`	All Admin API requests — logins, updates, config changes
`prc-ProcessImageFunction`	Image analysis and AI processing
`prc-LargeActionFunction` and `prc-ActionFunction`	Primary back-end worker logs — asset processing, integrations
`prcAssetRegisterFunction`	S3 event handler — new assets, deletions, Glacier state changes

Log groups follow the naming pattern: /aws/lambda/nomad-{name}-prc-{type} and /aws/lambda/nomad-{name}-web-api-{type}-mainEntryPoint.

DynamoDB History Table

Transactional data and the asset registry are stored in DynamoDB. The history table is the primary audit log:

One record per asset or content record update (Add, Change, Delete)
contentId — the specific record that was updated
lastModifiedUserId — who made the change
createdDate — when the change occurred

All tables also include lastModifiedUser and lastModified date/time fields on every record.

This history data is also surfaced in the Admin UI under the History tab for each asset or content item.

S3 Versioning

S3 versioning is enabled by default on all Nomad Media buckets. This provides a historical record of asset changes and enables recovery from accidental deletions or overwrites.