StretchVault stores five kinds of item. Choosing the right type keeps your vaults tidy, makes items easier to find, and gives Watchtower the right context for its security checks. This reference explains each type, the fields that matter, and when to reach for it.
Fields common to every item
Regardless of type, every item shares a common set of fields:
- Title (required) — how you'll recognize the item in lists.
- Secret — the confidential value, encrypted at rest and revealed only on demand.
- Username — an account name, login, or handle where relevant.
- URL — the sign-in page, host, or service address.
- Folder — an optional path to organize the item within its vault.
- Tags — labels for filtering and search.
- Notes — freeform context (stored as item metadata).
- 2FA flag — whether the account has two-factor authentication enabled.
Login
The default type, for a username/password pair on a website or app.
- Use it for: SaaS accounts, admin panels, social profiles, client dashboards.
- Fill in: username, URL (the sign-in page), and the password as the secret.
- Why it matters: the URL and username feed strength analysis — StretchVault warns you if your password contains the site name or your own username, which are easy for an attacker to guess.
Example: Title QuickBooks — Meridian, username finance@meridian.studio, URL qbo.intuit.com, password stored as the secret, 2FA flag on.
Secure note
Freeform confidential text with no fixed structure.
- Use it for: recovery phrases, license keys, Wi-Fi passwords, door codes, onboarding instructions, anything sensitive that isn't a login.
- Fill in: put the sensitive content in the secret (or notes) field; the title describes what it is.
- Why it matters: it keeps sensitive text out of chat apps and documents while still being shareable under permission.
Example: Title Google Workspace — Recovery Codes, with the codes stored as the secret.
Server
An infrastructure credential such as an SSH login or database account.
- Use it for: SSH users, database logins, VPS root passwords, SFTP accounts.
- Fill in: username (the account), URL/host (the server address), and the secret (password or key). Use notes for port numbers and connection strings.
- Why it matters: infrastructure credentials are high-value; grouping them as Server items makes them easy to audit and rotate on a schedule.
Example: Title Production DB — Primary, username app_rw, URL db.meridian.internal, password as the secret, connection details in notes.
API key
A token or key for a service integration.
- Use it for: payment gateway keys, email/SMTP tokens, analytics keys, third-party API credentials.
- Fill in: store the key as the secret; use the title to name the service and environment (Live vs. Test) so you never mix them up.
- Why it matters: API keys are often long-lived and forgotten — exactly the credentials rotation planning is built to catch.
Example: Title Stripe — Live Secret Key, key stored as the secret, notes recording which app uses it.
Payment card
A card you reuse for company purchases.
- Use it for: the company card teams use for subscriptions and ad spend.
- Fill in: the card number as the secret; put cardholder name, expiry, and billing address in notes.
- Why it matters: it centralizes a sensitive value that would otherwise circulate in messages, and keeps it behind the same reveal-and-audit controls as every other secret.
Example: Title Company Amex — Ads, card number as the secret, expiry and CVV guidance in notes.
Choosing the right type
When in doubt, ask what you'll do with the item. If you sign in somewhere, it's a Login. If it authenticates code or a service, it's an API key. If it connects to infrastructure, it's a Server. If it's money, it's a Payment card. Everything else is a Secure note.
Tips
- Always encode the environment (Live/Test/Staging) in API key and Server titles — it's the fastest way to prevent a costly mix-up.
- You can change an item's type later by editing it, so don't agonize over the choice up front.
- Use tags to cut across types — for example tag every client-owned item with the client name, regardless of whether it's a Login or an API key.
FAQ
Does the type change how the secret is encrypted? No. Every type is encrypted identically with AES-256-GCM. The type only affects fields, grouping, and context for security checks.
Can one item hold multiple secrets? Each item stores one secret value. For related values (like a key and its secret), create separate items or record the extra context in notes.
Was this helpful?
Help us improve this article
Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.

