Skip to content

Entities

Entities are the core building blocks of the Shoehorn service catalog. Every service, library, API, database, and infrastructure component is represented as an entity.

TypeDescriptionExample
serviceA running microservice or applicationPayment API, User Service
apiA standalone APIPublic REST API, GraphQL Gateway
frontendA frontend or UI applicationWeb Dashboard, Mobile App
libraryA shared library or SDKAuth SDK, Common Utils
databaseA data storePostgreSQL, Redis, Elasticsearch
systemA collection of related entitiesPayment System, Auth System
domainA business domainFinance, Customer Experience
resourceInfrastructure resourceS3 Bucket, Kafka Topic
componentA generic software componentCron Job, Lambda Function
platformA platform or runtimeKubernetes, AWS
teamAn engineering teamPlatform Team, Payments Team

Entities can be created from multiple sources:

SourceHowAutomatic
KubernetesK8s agent discovers workloadsYes
GitHub ManifestsCrawler reads .shoehorn/manifest.yml from reposYes
Backstage ImportCrawler reads catalog-info.yaml filesYes
ManualCreated via UI or APINo
TerraformCreated via Terraform providerNo

Each entity has a lifecycle stage indicating its maturity:

StageDescription
productionLive, serving production traffic
stagingIn staging/pre-production
developmentUnder active development
experimentalProof of concept or experiment
deprecatedScheduled for decommission
FieldDescription
NameDisplay name
Service IDUnique kebab-case identifier (e.g., payment-api)
TypeEntity type (see above)
OwnerOwning team
LifecycleCurrent lifecycle stage
TierService criticality, shown as Impact (critical, high, medium, low)
DescriptionHuman-readable description
TagsCategorization tags
FieldDescription
LinksExternal tool links (Grafana, ArgoCD, Docs, etc.)
RelationsDependencies and relationships to other entities
InterfacesAPI definitions (OpenAPI, gRPC, GraphQL)
RunbooksOperational runbooks
LicensesSoftware license tracking
ScorecardMaturity score and grade
  1. Navigate to Catalog in the sidebar
  2. Browse, search, and filter entities
  3. Click an entity to view its detail page
  4. Use the Edit button to modify attributes
Terminal window
# List entities
curl https://shoehorn.example.com/api/v1/entities \
-H "Authorization: Bearer <token>"
# Get a single entity
curl https://shoehorn.example.com/api/v1/entities/<id> \
-H "Authorization: Bearer <token>"
# Create an entity
curl -X POST https://shoehorn.example.com/api/v1/entities \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{
"name": "my-service",
"type": "service",
"lifecycle": "production",
"owner": "platform-team"
}'

The recommended approach for managing entities at scale. See Manifests.

The entity detail page includes these tabs:

TabContent
OverviewDescription, owner, tier, tags, links, relations
OperationsKubernetes workloads, pod status, GitOps sync
ScorecardMaturity score breakdown by category
ChangelogRepository changelog entries
ActivityRecent changes and events
GovernanceGovernance actions and compliance status
DocumentationREADME and embedded docs

Tier is the service’s declared criticality: how important it is and how badly users are affected if it degrades. It’s set by the author, separate from blast radius (the derived count of what depends on it).

TierDescription
criticalMission-critical, highest SLA
highImportant, high SLA
mediumStandard, normal SLA
lowBest-effort, low SLA

The metal words platinum, gold, silver, and bronze still work in manifests as legacy aliases. They map to critical, high, medium, and low.