Security Settings

Security in wallmarkets is strongest when you stay close to the features that actually exist today.

That means focusing on three practical areas:

• password hygiene
• API key hygiene
• keeping account ownership clear

This guide is intentionally grounded in the current UI instead of an imagined enterprise security console.

Password changes

The main security action exposed in Account Settings today is password change.

When you update your password:

• you must provide the current password
• you should choose a new password you do not reuse elsewhere
• you should treat the change as a reason to review who still has access to the account

If an account has been shared casually across teammates, a password change is the cleanest moment to stop that habit.

Keep the password boringly strong

A good password does not need to be clever. It needs to be unique and hard to guess.

The practical rules:

• do not reuse it on another service
• use a password manager if possible
• change it when ownership or trust changes

Most account problems start with weak process long before they start with exotic attacks.

Two-factor authentication status

The account settings UI currently shows two-factor authentication as coming soon.

That means you should not document 2FA internally as if every reader can enable it right now from the page. When that area is fully live, it will deserve its own rollout message. For now, treat it as planned rather than universally available.

API keys

If you use the API, the most important security surface after the password is the API keys page.

The current flow is simple:

• create a named key
• copy it immediately when it is shown
• store it somewhere secure
• revoke it when it is no longer needed

There is also a hard limit on how many keys one account can keep, which is useful pressure to avoid leaving stale credentials lying around.

Practical API key habits

These habits are worth enforcing inside your team:

• create separate keys for separate applications
• use descriptive names so old keys are easy to identify
• never paste keys into chat, tickets, or source control
• revoke unused keys instead of letting them accumulate

The app also surfaces a standard request limit on the API key page, so treat repeated 429 responses as a signal to improve the client instead of creating more keys to work around it.

Notifications and account awareness

The preferences area keeps security alerts treated more seriously than optional notifications.

That is a good default. If something security-related changes, the goal should be that the account owner notices quickly rather than optimizing for fewer emails.

If something feels wrong

If you suspect the account or an API key has been exposed:

1. change the account password
2. review and revoke API keys you do not trust
3. stop using shared credentials immediately
4. contact support if you need help stabilizing the account

Fast, simple action beats waiting for perfect certainty.

What this page does not currently provide

Readers often expect to find a full security operations surface here: active sessions, audit logs, enforced team-wide role policy, fully rolled-out 2FA, and so on.

That is not the right assumption for the current product. Work from the controls you can see today, and avoid writing process documents that depend on UI that is not actually there yet.

Related guides

• Updating your profile
• Managing users and permissions
• Billing and subscription