Integrations overview

TokenTimer connects directly to secret management platforms, source control systems, and cloud providers to discover expiring credentials, certificates, and keys, then imports them as tokens.

Supported providers:

Provider	What is discovered	Auto-sync
HashiCorp Vault	KV v2 secrets, PKI certificates	No
GitHub	Repository secrets, deploy keys, SSH keys	Yes
GitLab	Personal, project, group, deploy, and pipeline trigger tokens, SSH keys	Yes
AWS	Secrets Manager secrets, ACM certificates, IAM access keys	No
Azure Key Vault	Secrets, certificates, cryptographic keys	No
Microsoft Entra ID	App registration secrets and certificates, service principal credentials	No
GCP Secret Manager	Secrets with expiration dates	No

You can also import tokens from files (CSV, XLSX, JSON, YAML) and use the Domain Checker to discover subdomains and import live SSL certificates.

Security and privacy

Security & Privacy

• One-time use: credentials you provide for a manual scan are used once and are not stored, unless you explicitly set up auto-sync for a provider that supports it (see below).
• Metadata only: TokenTimer retrieves only metadata (names, expiration dates, locations). No secret values, private keys, or sensitive data are read or stored.
• Your control: for one-time scans, you provide credentials at scan time and they are discarded immediately after. For auto-sync, credentials you provide are encrypted at rest on your own infrastructure and used only by the scheduled worker.
• Best practice: for one-time scans, create temporary credentials with minimal permissions and revoke them after use.

Auto-sync (scheduled re-scans)

Self-hosted TokenTimer can re-scan GitHub and GitLab on a schedule instead of requiring a manual scan every time. Auto-sync stores the credential encrypted in your own database and the worker uses it to run periodic scans automatically, importing new and updated tokens without any user interaction.

• Supported providers: GitHub and GitLab only. Vault, AWS, Azure Key Vault, Entra ID, and GCP Secret Manager do not support auto-sync; scan them manually whenever you want fresh data.
• Scheduling: controlled by the WORKER_AUTO_SYNC_CRON (Docker Compose) or the worker CronJob schedule (Helm). See Worker scheduling.
• Audit trail: every create, update, delete, manual trigger, and failure is recorded as an AUTO_SYNC_* audit event. See Auto-Sync events.
• Provider setup: see the "Auto-sync" section on the GitHub and GitLab pages.

This is a self-hosted-only capability: TokenTimer Cloud never stores integration credentials, so every scan there is a one-time action.

Filter rules

Every provider scan supports an optional, ordered list of include/exclude filter rules to control exactly which discovered credentials get imported:

• Each rule has an action (include or exclude), a match type (exact value or regular expression), a field (name or description), and a value.
• Regular expressions use JavaScript (ECMAScript) syntax, evaluated on the server.
• Exclude rules always win over include rules.
• If at least one include rule is defined, only items matching an include rule are imported (allowlist behavior). With only exclude rules, everything except the matches is imported (denylist behavior). With no rules, everything is imported.
• After a scan, the preview shows matched vs excluded counts, and each row has a one-click "exclude" action that adds an exact-match exclude rule.
• Invalid regular expressions are rejected with a clear error before the scan runs.
• For safety, regular expressions with nested quantifiers (for example (a+)+ or (a*)*) are rejected, since that shape can cause catastrophic backtracking and hang the server or worker process. Matched field values are also capped at 2000 characters for matching purposes, so an unusually long name or description cannot slow down a scan or a scheduled auto-sync run.
• Rules are persisted with the auto-sync configuration and applied on every scheduled run, so tokens excluded by rules never enter the inventory and never trigger alerts.
• Most token types (for example GitLab personal/project/group/deploy tokens and GitHub secrets) have no separate description metadata at the source, only a name. For those, matching on the description field falls back to the item's name, so a rule targeting "description" still works as expected.

The rule editor is available in the GitLab and GitHub import forms; the underlying API applies rules to every provider scan and import.

Typical use case: platform teams that provision tokens via IaC embed a consistent marker in the token description and use one include rule like ^iac-provisioned:.* on the description field so TokenTimer only tracks platform-owned tokens.

Obsolete-token cleanup

When importing from GitLab or GitHub (manually or via auto-sync) you can enable "Remove previously imported tokens no longer found at the source". After the import, TokenTimer hard-deletes previously imported tokens that belong to the same provider and the scanned token types but were not rediscovered by this scan, regardless of which items you actually chose to import. Token types you did not include in the scan are never affected. Each deletion is recorded as a TOKEN_DELETED audit event.

• The cleanup is scoped to the token types actually included in the scan: a scan without SSH keys never deletes SSH key entries.
• Tokens excluded by filter rules count as "not rediscovered" and are removed when cleanup is enabled.
• On auto-sync runs, cleanup is skipped entirely when a scan returns zero items, so a failing or empty scan can never mass-delete a workspace.
• The setting is off by default, persisted with the auto-sync configuration, and deletions cannot be undone.

Expiration dates

Some platforms do not expose expiration dates for certain token types (for example GitHub SSH keys and AWS IAM access keys). These tokens are imported with an expiration date of 2099-12-31 and displayed as Never expires throughout the dashboard. You can update their expiration dates manually at any time.

Automatic deduplication

When importing tokens, TokenTimer prevents duplicates by matching on both name and location. Importing the same token again (same name + same location) updates the existing token instead of creating a duplicate.

• Example: import "Database Password" from aws:secretsmanager:us-east-1:arn:.../db-password on day 1, then import it again on day 2 with an updated expiration date. The existing token is updated, not duplicated.
• Different tokens: tokens with the same location but different names are treated as separate tokens (for example "Production API Key" vs "Staging API Key" at the same path).
• File imports: for CSV/XLSX/JSON imports, include a location column for reliable deduplication.
• Alert catch-up: alerts for thresholds that have already passed are suppressed at import to prevent notification storms. Alerts resume as the next future threshold is reached.