For LLM agents: documentation index at
/llms.txt, full text at
/llms-full.txt. Append .md to any page URL for plain markdown.
Query your data assets (tables, views, models) discovered by AnomalyArmor.
List Assets
Query Parameters
Example Request
Example Response
Get Asset
Retrieve a single asset by qualified name or UUID.
Path Parameters
Example Request
Example Response
Asset Identification
AnomalyArmor supports two ways to identify assets:
Qualified Name (Primary)
Human-readable, hierarchical identifier:
Examples:
snowflake.prod.warehouse.orders
databricks.main.analytics.daily_sales
postgresql.app_db.public.users
Use qualified names in code for readability. They’re stable as long as you don’t rename the underlying table.
UUID (Secondary)
System-generated unique identifier. Use for automation where names may change:
Error Responses
Common Questions
Should I identify an asset by qualified name or UUID?
Use the qualified name (source.database.schema.table) for code and config you read by hand: it survives re-discovery and is human-debuggable. Use the UUID for automation where names might be renamed upstream, since UUIDs are stable across renames. Both identifiers work on every /api/v1/assets/{id} endpoint.
How does AnomalyArmor discover assets?
Assets are discovered automatically when you connect a source (Snowflake, BigQuery, Postgres, etc.) via the dashboard. The Assets API is read-only; it returns whatever the platform has discovered so far. If an expected table is missing, trigger a re-scan from the source’s page in the dashboard.
Does listing assets return column-level details?
No. GET /api/v1/assets returns metadata and row/column counts. To get the column schema (names, types, nullability, primary keys), call GET /api/v1/assets/{id} for a single asset. That keeps list responses small and fast when you have hundreds of tables.