Skip to main content
CloudEnterprise

Technical Information

This document covers the Lightyear to NetBox object mappings, API details, and configuration reference for the integration.

Synchronized Object Types

The integration discovers and ingests four NetBox object types from the Lightyear service inventory:

NetBox ObjectSourceNotes
CircuitTypeLightyear service typeDeduplicated by slug across all services
ProviderLightyear provider nameDeduplicated by slug across all services
ProviderAccountLightyear provider account numberOnly created when provider_account_number is present
CircuitLightyear service (summary + detail)Two-phase API fetch per service

CircuitType

Lightyear service type values are transformed into NetBox CircuitType objects.

Lightyear FieldNetBox FieldTransformation
service_typenameUnderscores replaced with spaces, title-cased
service_typeslugSlugified (underscores replaced with hyphens)

Example: wan_sd_wan → name Wan Sd Wan, slug wan-sd-wan

Duplicate service types across all services are deduplicated by slug before ingestion — only one CircuitType is created per unique slug value.


Provider

Each unique provider name in the Lightyear service list becomes a NetBox Provider.

Lightyear FieldNetBox FieldTransformation
providernameUsed directly
providerslugSlugified from name

Providers are deduplicated by slug — if multiple services reference the same provider name, a single Provider entity is created.


ProviderAccount

Provider accounts are created when a service includes a provider_account_number value.

Lightyear FieldNetBox FieldTransformation
provider_account_numberaccountUsed directly
providerproviderReference to the associated Provider entity

ProviderAccounts are deduplicated using a composite key of provider_slug::account_number. Services without a provider_account_number do not generate a ProviderAccount.


Circuit

Circuit objects are built from a two-phase API fetch: a service summary call followed by a per-service detail call.

Lightyear FieldNetBox FieldSourceNotes
details.provider_service_idcidDetail callFalls back to "Undefined" if absent
statusstatusSummarySee status mapping below
service_typetypeSummaryReference to CircuitType
providerproviderSummaryReference to Provider
provider_account_numberprovider_accountSummaryReference to ProviderAccount; omitted if no account
start_dateinstall_dateDetail callParsed from ISO 8601
end_datetermination_dateDetail callParsed from ISO 8601; omitted if absent

Circuit Status Mapping

Lightyear StatusNetBox Status
activeactive
inactiveoffline
in_progressprovisioning
pendingplanned
cancelleddecommissioned
Any other valueplanned

API Details

Endpoints

EndpointPurpose
GET /developer/services/v1Retrieve full list of services (summary data)
GET /developer/services/{id}/v1Retrieve detailed information for a single service

Authentication

The Lightyear API uses HMAC-SHA256 signed requests:

  • Signature: HMAC-SHA256(api_secret, "path::body::timestamp")
  • Header: Authorization: LY-HMAC Key=<api_key>,Timestamp=<unix_timestamp>,Signature=<signature>
  • Credentials required: LIGHTYEAR_API_KEY and LIGHTYEAR_API_SECRET

Rate Limiting and Retries

ParameterValue
Max retries3
Retry delays5s, 10s, 20s (exponential backoff, max 60s)
Retry-After headerRespected if present in 429 response

If the rate limit is exceeded after all retries, the run is aborted with an error.


Policy Configuration

ParameterRequiredDefaultDescription
lightyear_api_keyYesLightyear API key for authentication
lightyear_api_secretYesLightyear API secret for HMAC signature generation
lightyear_hostNohttps://api.lightyear.aiOverride the Lightyear API base URL
scheduleNoCron expression controlling how often the agent runs; omit to run once and exit

Tags and Metadata

All entities created or updated by the integration are tagged with:

  • lightyear
  • discovered

These tags are applied to all object types (CircuitTypes, Providers, ProviderAccounts, and Circuits), making it straightforward to filter Lightyear-sourced data in the NetBox UI.