Nest Engineering Docs
Partner Credentials

Architecture

System design and data flow for Partner Credentials

Partner Credentials is a Python 3.13 FastAPI service that brokers partner auth tokens for internal services.

System context

Internal services -> PartnerCreds (FastAPI)
                       |-> Spanner (Organizations)
                       |-> Secret Manager
                       |-> Partner token endpoints (ezyVet, Bitwerx, HAP)
                       |-> Sentry

Request flow

  1. An internal service calls GET /api/v1/auth/pims/token?oid=....
  2. PartnerCreds loads organization metadata from Spanner.
  3. The provider and auth type are derived from the organization record.
  4. The token cache is checked; on miss, a token is fetched from the partner token endpoint.
  5. A NestAuthResponse is returned with access_token or api_key.

Components

  • services/partnercreds/main.py: app setup, Sentry, and Spanner lifecycle.
  • services/partnercreds/api/v1/endpoints/pims.py: token issuance endpoint.
  • services/partnercreds/util/data_access_manager.py: Spanner access layer.
  • services/partnercreds/util/token_cache_manager.py: TTL cache + refresh.
  • services/partnercreds/core/token_processor.py: provider-specific logic.
  • services/partnercreds/core/fetcher.py: partner API calls via httpx.
  • services/partnercreds/core/security.py: Secret Manager lookups.
  • services/partnercreds/models/auth.py: request/response models.

Reliability and scaling

  • In-memory cache is per-instance; tokens may be fetched by multiple instances.
  • Per-token asyncio locks prevent stampedes within a single instance.
  • Token requests enforce timeouts and TLS 1.2 for partner API calls.
  • Failures surface as 5xx responses so callers can retry.

Last updated on