Security best practices

TextKit secures the platform; you secure your side of it. This page covers what we do, what you should do, and how to recognize the attacks that target messaging accounts.

Protect your API keys

• Admins can view and copy a key from the console; members and viewers can't. Every view is in the audit log, and the key itself is never logged. Keys are looked up by keyed hash and kept encrypted at rest.
• Keep keys in environment variables or a secrets manager, never in source control, client-side code, or chat logs. A key in a public repo should be treated as compromised and rotated immediately.
• Rotate keys periodically (we recommend at least every 90 days) and on any team departure. Rotation is instant in the console under API keys.
• Use test keys everywhere except production. Test keys cannot send real traffic, so a leaked test key cannot run up a bill or spam anyone.
• Give each service a restricted key with only the scopes it needs, and set a spend limit so a leaked live key has a ceiling.
• Review the audit log for key and team changes you don't recognize.

Protect your account

• Console passwords must be at least 12 characters with uppercase, lowercase, numeric, and special characters. Use a password manager and a unique password.
• Accounts lock temporarily after repeated failed sign-in attempts, and console sessions on a device expire after 30 days of inactivity (every sign-in still needs its one-time code).
• Every password sign-in after the one that creates your account needs a one-time code (by text to your verified phone, or email), and you can add an authenticator app under Settings. After 30 wrong authenticator codes in a day (or 50 wrong texted or emailed codes), that kind of code is refused until the next day; the other kind still works, and you are emailed.
• Sign out everywhere (Settings) ends every sign-in to your account at once, this one included. Resetting your password does the same.
• Only invite teammates who need access, and remove them when they leave.

Security emails

We email you when something changes that could mean someone else is in your account. They go out whatever your email preferences, and none of them carries message content or a full key:

If one of these was not you or someone on your team: reset your password, roll your API keys, and reply to the email so we can lock the account while you sort it out.

Unusual API key activity

We watch every live key against its own history (test keys can't reach a real phone, so they aren't watched):

• A new country. The first time a key makes a request from a country it hasn't used before, the account owner and admins get an email (the very first country a key is used from is where it lives, not news).
• A sudden spike. When a key's requests today pass 500 and ten times its daily average over the previous week, the owner and admins are emailed and our team is told. Nothing is paused.
• Both together. A spike from a country the key started using in the last day is how a stolen key looks, so we pause the key: calls with it get 403 key_paused, everything else on the account keeps working, and the owner and admins are emailed. An admin can resume it under API keys if it was them (it won't be paused again that day), or roll it.
• Blocked messages. When our content checks block far more of the account's messages than usual (at least 20 in a day and five times its daily average), the owner and admins are emailed and our team takes a look.

We check every 10 minutes. These alerts carry counts, the key's name and first characters, the country and IP address; never message content.

Recognize social engineering

Messaging accounts are a target: attackers want your sending capability, your keys, or your customers' trust.

• We will never ask for your password or a full API key - not by email, not by text, not in support conversations. Anyone who does is not us.
• Verify unusual requests out of band: if an email or message asks you to change payment details, share credentials, or approve access, confirm through a channel you already trust (the console, or a contact you already have) before acting.
• Check sender addresses carefully. Our email comes from the joinsimplesms.com domain and links point to jointextkit.com; lookalike domains are the most common phishing tell.
• Spear phishing is personalized - a message knowing your name, role, or vendor list is not proof it is genuine.
• Report anything suspicious to support@joinsimplesms.com; we investigate every report.

Protect your users

• Send only to recipients who opted in, honor opt-outs (we enforce STOP and its variants platform-wide), and identify yourself as the sender - see Opt-out & consent.
• Never put credentials, one-time codes you did not generate, or sensitive personal data in outbound messages beyond what the use case requires.
• Verify webhook signatures so spoofed callbacks cannot inject fake delivery or inbound events into your systems.

What we do on our side

• TLS for all data in transit; encryption at rest; API keys stored as keyed hashes and verification codes as salted hashes, never logged in plaintext.
• Real-time content filtering, velocity limits, and 24x7 automated fraud monitoring with automatic suspension of abusive traffic.
• Production access restricted to authorized personnel and audited.
• Details in the Privacy Policy.

Found a vulnerability? Email support@joinsimplesms.com with details; we respond quickly and appreciate responsible disclosure.