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
HashiCorp Vault	KV v2 secrets, PKI certificates
GitHub	Repository secrets, deploy keys, SSH keys
GitLab	Personal, project, group, deploy, and pipeline trigger tokens, SSH keys
AWS	Secrets Manager secrets, ACM certificates, IAM access keys
Azure Key Vault	Secrets, certificates, cryptographic keys
Microsoft Entra ID	App registration secrets and certificates, service principal credentials
GCP Secret Manager	Secrets with expiration dates

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 scan are used once and are never stored.
• Metadata only: TokenTimer retrieves only metadata (names, expiration dates, locations). No secret values, private keys, or sensitive data are read or stored.
• Your control: you provide credentials at scan time. After scanning, credentials are immediately discarded.
• Best practice: create temporary credentials with minimal permissions and revoke them after use.

If you want TokenTimer to re-scan a provider on a schedule, note that scheduled re-scans (auto-sync) are not available on TokenTimer Cloud: the hosted service never stores your integration credentials, so every scan is a one-time action with credentials you provide at scan time. Self-hosted TokenTimer supports auto-sync for GitHub and GitLab with encrypted credentials stored on your own infrastructure.

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. Matched field values are also capped at 2000 characters for matching purposes, so an unusually long name or description cannot slow down a scan.
• 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 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.
• The setting is off by default 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.

Scan quota

Integration scans are metered per workspace per month. The Free plan includes 3 scans per month; Pro and Team plans have unlimited scans. See Plan limits for the full quota table.

Self-hosted endpoints behind an allowlist

If your self-hosted GitLab, GitHub Enterprise, Vault, or other integration endpoint restricts inbound traffic by IP, allow TokenTimer Cloud's egress IP first. See Egress IP allowlisting.