External Authentication Management for Segment Functions

Avoid hammering authentication endpoints by refreshing tokens outside the function runtime.

Why this exists

Segment Destination Functions cannot cache authentication tokens for the full ttl; in some cases, every call can hit your authentication server.

Off-loading token requests to a CI job means:

• Rate-limit safety - one token fetch per rotation window, not per event.
• Faster functions - no network round-trip for authentication.
• Simpler functions - no need to handle authentication logic in your function code.

How it works

1. A GitHub Actions workflow runs a script on a schedule (or manual trigger).
2. The script calls your AUTHENTICATION_ENDPOINT to retrieve a token.
3. It writes the token into the Function Setting of one or more Desitnation Function Instance Ids using DESTINATIONS_TO_UPDATE.

flowchart TD
  A[GitHub Actions] -->|GET token| B(Auth Endpoint)
  B -->|Segment Public API| C[Destination Function Settings]
  C -->|Runtime uses stored token| D(Segment Function)

Loading

Requirements

• Segment Destination Instance Ids (Not Function Ids)
• Function Setting to be updated that stores the token
• Segment Public API Token

GitHub Environment Secrets

• AUTHENTICATION_ENDPOINT: Endpoint to request authentication tokens
• ...Other Authentication Endpoint Variables...
• PUBLIC_API_TOKEN: Public API Token for Segment

GitHub Environment Variables

• DESTINATIONS_TO_UPDATE: Pipe-separated list of Segment Destination Function Instance Ids (e.g., dest-123|dest-456)