TextKit
Plain text (Markdown)

Privacy Policy

Last updated: October 29, 2026

The short version

  • When you send messages through TextKit, the phone numbers and texts are your data. We process them for you, on your instructions.
  • We collect a little about you (account, billing, usage) to run the Service.
  • We do not sell personal data, use message content for ads, or use it to train general-purpose AI models.
  • Automated screening, including AI classifiers, reads messages only to stop fraud and abuse, to check that they match the registration they are sent under, and to honor opt-outs.
  • Got a text from a business on TextKit? Reply STOP. Questions go to privacy@joinsimplesms.com.

This policy describes how Truelabel Inc, doing business as "TextKit" ("we", "us"), handles personal data in connection with the TextKit platform and websites (the "Service"). The Service was called "SimpleSMS" until October 2026, and "Delivered" before that; only the name and web address changed.

1. Two Roles

Our customers' data: we are the controller. For information about the developers and businesses who use TextKit (accounts, billing, support, website visits) we decide how it is used, and this policy describes it.

Message data: we are a processor. When customers send us phone numbers, email addresses to send verification codes to, message content, contact lists, or other information through the API or console, we process it on the customer's behalf and on their instructions, under our Data Processing Addendum. The customer decides why it is processed and is responsible for having a lawful basis, such as consent, to message each recipient. If you received a text from a business that uses TextKit, that business's privacy policy governs how it uses your information; Section 9 explains how to reach it through us.

2. Data We Collect

Account data. Name, email, company, and sign-in identifiers (including the phone number or authenticator app you set up for two-step sign-in); a record in your account's message log of each security or verification code we text for the account (the code itself hidden; a team member's sign-in phone and the owner's phone shown by their last four digits only, a test recipient's number in full), so your team can see a code was sent; the browsers you sign in to the console from (a random identifier kept in a cookie, the browser type, the approximate city, region and country our hosting provider derives from your IP address, and when we first and last saw it), so we can email you about a sign-in from a browser we have not seen; for each live API key, the countries it has been used from (as our hosting provider derives them from the IP address of each request) and how many requests it made each day, so we can tell you, and pause the key, when it looks stolen; business and registration details (legal name, address, tax ID, website, use case) that carriers require to register your brand and campaigns, and the results of the automated check we run on the public web pages you submit for registration (findings and short excerpts of those pages, not the pages themselves); when you ask us to fill in a registration or a toll-free verification form from your website, open a toll-free verification form while we know your website, or open the console's first-text guide after signing up with a business email address (we read the website at that address to suggest an example text for your industry), the details we read from those public pages (business name, contact details, address, industry, and which pages hold your opt-in form, privacy policy and terms), kept for about 10 minutes so that asking again does not read your site again, and any draft example messages we suggest, kept with the registration until you replace or confirm them; the example messages, the description of what you send, your account of how people opt in, and your wording of the opt-out and help replies that you write for a registration, the name, job title, work email and phone number of the person you name as the business's authorized representative, the area code or number you ask for with it, the business attestation that someone authorized to act for the business signs before we first file a registration for it (the exact statement agreed to, the name and title typed, whether it was signed in the console or sent through the API and by which user or API key, the IP address and browser it was signed from, the time, and the date of these documents at the time), which we keep unchanged, and our record of whether we verified the business and why (including the checks we ran: whether the representative's email domain matches the website and accepts mail, whether another account has registered the same tax ID, whether the business's names or the representative's name match a name on the US Treasury's sanctions list (OFAC), and when the account was created), and a copy of exactly what we filed for carrier review each time you submit one (your business details, those examples and description, how the checks stood, and your acknowledgment of the registration fee terms: the wording you accepted, when, and the IP address it came from), which we keep unchanged so that you and we can show what was reviewed; the registration fees recorded on your account (what each is for, its amount, and whether it is invoiced or paid); the answers you give when you request live access (company, website, expected volume, message types, how recipients opt in, countries, and use case), which we take from your registration when you submit one from a sandbox account instead of asking again; the answers you give when you request a toll-free number or a short code (business name, expected volume, and use case); the toll-free verification form you submit (business name, address, tax ID, a contact's name and phone, your numbers, expected volume, a description of your messages with examples, how people opt in, and your website, terms and privacy addresses), which we fill in for you to check only from what you already gave us (from your registration: the business, its address, tax ID and contact, what you send with its description and examples, and how people opt in, as you answered them there; from your account: your email, your numbers, the website and volume from your live-access request, and an opt-in page you turned on) and from your website's public pages as described in section 4 (your legal name, brand, address, tax ID and nonprofit status, each only when your pages state it, and your own privacy policy and terms: where still blank, or in place of the earlier answers when you press Fill from website or give another business's website); what you send, its description and how people opt in are never filled from your website, and a suggested wording is used only if you choose it, and send to the carriers when you submit it, with a screenshot of the opt-in page and your business's own email as the contact email (we send it from our support address, so the carriers' replies come to us); where each of your phone numbers stands with the carriers (its registration status, the registration it is linked to, and the history of those changes); the setup path you start in the console (for example moving from another provider), which only decides which setup steps we show you; team members you invite (we send the invitation to the email address you give us, and keep that address with the pending invitation until it is accepted or revoked, or is cleared after it expires). When you sign up we check that your email address can receive mail (its format, a list of disposable email domains, and the domain's public DNS records); no outside service sees the address.

Billing data. Plan, credit purchases and balance, a ledger of what your credits paid for, monthly statements, and payment status. Card details are held by our payment processor, never by us; we keep only the card brand and last four digits so you can recognise it.

Support data. What you send us when you contact support, including feedback you share from the console and, when you rate an answer from TextKit Agent, that answer and the question it answered.

Abuse reports. If you report a text on our report form (/report), the number that texted you, your phone number, what happened and any note you add. Our team uses it to investigate and to stop the texts; the business you report never sees your number.

Texting plan requests. If you use the texting plan on our website (/plan), the website address you enter and the plan we make from its public pages (the business details we read there and our suggestions), kept for about 10 minutes so that asking again does not read the site again. The plan is kept by website, not by who asked. To limit abuse we count requests from each network address; those counts are deleted within about two days.

Text-me samples. If you enter your website and mobile number on our try page (/try), we text that number a one-time code and, once you enter it, one sample text drafted from your website's texting plan (above), at most one sample a day. We keep the code salted and hashed, with your number only as a one-way hash, for about 10 minutes and delete it as soon as it is used. Once your number is verified we hold it for up to 30 minutes so the account you create next starts with it verified; it is read once and deleted, or deleted when the 30 minutes run out. We log each text we send you, with only the last four digits of your number, so its delivery receipt can be matched. To limit abuse we count codes and samples per network address and per hashed number; those counts are deleted within about two days. We do not add your number to any list or text you again unless you create an account.

Product update subscriptions. If you sign up for product updates on our website or in console settings: your email address, where you signed up, and when you confirmed or unsubscribed. Website sign-ups are double opt-in: we email nothing but the confirmation link until you confirm, and every update carries an unsubscribe link.

Message data (processed for customers).

  • Message content: SMS and MMS bodies and media you send or receive. You can delete or redact a message through the API once it is delivered, failed or received (Data Retention says what each removes and what is kept).
  • Message metadata: sender and recipient numbers, timestamps, message IDs, delivery status and carrier receipts, routing and carrier information, error codes, and any tags you attach to a message.
  • Consent records: opt-ins, opt-outs, STOP and HELP replies, and the keyword or phrase that triggered them; the fact and time of any message a customer tried to send to a number after it opted out (not its content); and any opt-in evidence a customer records with us (how and when consent was given, the page and disclosure wording shown, the IP address and browser user agent of the person who opted in, the registration the opt-in was given for, and for a keyword opt-in the inbound message that was the opt-in), including the opt-in status, date, source, page and registration in a contact list a customer imports; the re-confirmation texts we send on a customer's behalf, when they were sent, the reply or its absence, and the one marketing message held while we wait (as the customer wrote it, in the customer's message log); when someone signs up on an opt-in page we host for a customer, the number, the time, the page, the exact consent wording shown, and the IP address and browser user agent of the sign-up, recorded on the customer's behalf as a request (including a sign-up from a number that has opted out, which we keep as a record but which does not opt it back in), the text we send asking them to confirm, and their YES reply, which makes it an opt-in (an unconfirmed request is held for 7 days to match a reply, and kept as a record); and each number's subscription preference per topic, with when it changed, where the change came from, and who made it.
  • Contact records: the contacts a customer keeps with us: phone number, name, email address, company, state or province, tags, custom fields, notes, where the contact came from, which import added it, and which of the customer's lists it is in; the lists (fixed groups), segments (saved filters) and subscription topics the customer defines; and which broadcasts a number was included in.
  • Connected tools: when a customer connects one of its own tools (an online store, a CRM, an analytics or customer-data platform), the settings it chose, the credential it gave us to read that tool or, when it connected with one click, the read access it approved in that tool (stored encrypted, never shown again, deleted when the customer disconnects, and then also revoked in the tool where the tool allows), a fingerprint of the token that tool uses to send to us, and counts from each sync. When a tool tells us the customer removed our access, we stop reading it; when it passes on a person's request to delete their data, we delete the contact records that tool gave us (a do-not-text record stays, so they are not texted again). What we read from the tool becomes contact records like any import: phone number, name, email, company, state, the record's id in that tool, and the SMS consent state when the tool records one (a consent field, or membership of a group the customer built from the tool's own record of people agreeing to texts). We read only what the customer points us at, only to keep its contacts and lists in step, and an unsubscribe in the tool is recorded as an opt-out here. When a customer has connected an online store and turns on an automation that starts on an abandoned checkout, we also read that store's abandoned checkouts and new orders every 10 minutes: the shopper's phone number, the checkout link, the total, the item count and the first item's name, kept as automation events, and the checkout's id in the store, kept 14 days so each cart is texted at most once. A cart becomes a reminder only for a shopper the store records as subscribed to text marketing, or who already opted in with the customer; a reminder is a marketing message and passes every consent check one does. When the customer turns on an automation that starts on a new order or a shipment, we also read that store's new orders and shipments, every 10 minutes and, for a store connected with one click, as the store reports them: the shopper's phone number, the order number, its status page link, the total, the item count and the first item's name, and a shipment's tracking number, link and carrier, kept as automation events, and each order's and shipment's id in the store, kept 14 days so each is used at most once. An order or shipping text goes only to a shopper who opted in with the customer or whom the store records as subscribed to text messages. We stop reading them when no such automation is active.
  • Verification data: the phone number or email address a verification code was sent to (both, when a code that was texted is then emailed), the app name it was sent under, and the outcome. Codes are stored only as salted hashes and never logged in plaintext. Limits on how many codes one address or domain may receive are counted under one-way hashes, never the address itself.
  • Lookup data: numbers you look up and the carrier and line-type results.
  • Customer records: if you send for other businesses and use the customers API, the names, your identifiers, and metadata you store for them, and per-customer usage counts.
  • Automation data: if you use automations, the events you send us about your users (the event name, the user's phone number, your own identifier for the user, and any properties you attach), the link between your identifier and the phone number, the flows you build (including their message text), and a record of each run: who it was for, the steps it took and when, and why it ended.
  • Schedule data: if you use recurring schedules, the recipient's phone number, the message text, the repeat rule and time zone you set, and a record of each occurrence: its date, whether it was sent, skipped or failed, and the id of the message it produced (never the message text).
  • Short links and clicks: if a customer turns on link shortening, the domain it adds for short links and its DNS check results; for each link in a message, the original link, its short link and the message it was sent in; and when someone opens a short link, a count of opens, the time of the first and last open, and the kind of device (phone, computer, or a link preview fetched by a messaging app), read from the browser's user agent. We do not keep the IP address or the user agent of the person who opened the link. Opens are reported to the customer (on the message and as a webhook event).

Usage and device data. API request logs, IP addresses, usage counters, delivery statistics, and rate-limit and fraud signals; an audit log of changes to your account (who made each change, when, and from which IP address); when you sign in a command-line tool, the machine name it reports and the IP address it asked from, shown to you so you can decide whether to approve it; website and console analytics and session recordings (masked; Section 8), subject to the consent controls in Section 8; and account-level usage metrics (Section 8).

Automated-agent traffic. We count requests from self-identified AI crawlers and agents by user agent and path, and keep the counts 400 days; this contains no personal data.

3. How We Use Data

  • To provide the Service: transmit messages through carriers, send verification codes by text or email, provision numbers, run the inbox, meter and bill usage, and provide support.
  • To keep the network safe: detect and prevent spam, phishing, SMS pumping, fraud, and other abuse; enforce our Messaging Policy; maintain opt-out and abuse registries; and meet carrier, registry, and regulatory requirements such as A2P 10DLC registration.
  • To comply with law and respond to valid legal requests (Section 7).
  • To improve the Service, using account and usage data and aggregated metadata. We do not read message content to improve the product.
  • To communicate with you about your account, the Service, and changes to it, including a code to confirm your email address when you sign up with a password, and security notices: a new API key on your account, a sign-in from a browser we have not seen, a change to your two-step sign-in or your password, many wrong sign-in codes entered for your account in a day, and someone joining your team; and billing notices: a receipt for each payment, a refund, a phone number bought or released, a declined card, and a low or empty balance. These go out whatever your email preferences, because they are how you would notice someone else using your account or know what you were charged. About an hour after an account is created, its owner also gets one short welcome note from our founder; a reply goes to him directly. It is sent once, and not to an address that unsubscribed from our product updates.

We do not sell personal data, use message content for advertising, or "share" personal data for cross-context behavioral advertising.

4. Automated Processing and AI

Most of the Service involves no AI: sending a message through the API is routing, not analysis. Message content passes through automated systems only in these cases:

  • Trust and safety screening. Before a live message is sent, our content screen checks it with rules and two third-party AI models: a moderation model for the prohibited and restricted content in the Messaging Policy, and a classifier for phishing, impersonation and scams. The classifier is also given the business name and website filed on the sending number's registration or toll-free verification, so it can tell a business's own alerts from imitations of them. A message blocked by this screen, with up to 320 characters of its text, is kept for review and shown in your message log. A message the screen could not check is not sent. A message refused for another reason (an opt-out, quiet hours, a missing opt-in, an unregistered sender, an allowance or a limit, or an account that is closed or suspended) is not analyzed; it is kept in your message log like any other message, marked as blocked with the reason.
  • Checking a message against its registration. The first time a number linked to a registration (or a toll-free number verified through our form) sends a new kind of message, a third-party AI classifier compares it with the registration or toll-free verification as filed (its use case, description, example messages, business name and website) to decide whether it fits and whether it is promotional. The classifier receives the message's text with names, numbers, amounts, email addresses and links masked, never the recipient's number. We keep its answer and a one-sentence reason for each kind, not the text, so later messages of the same kind are not sent to it again. A kind it finds does not match is refused; one it cannot place is held for a person on our team, as below. Messages from a two-factor registration are not sent to it.
  • Checking links. For a number linked to a registration, or a toll-free number verified through our form, we compare each link in a message with the domains its registration or verification allows, and our server visits a link once for each kind of message to see where its redirects lead, reading no page content. We keep, for each kind of message and link domain, whether it passed and where it led (never the full link) for 7 days. This is fixed rules, not AI.
  • Review of new kinds of message (by people). During an account's first 30 days of live sending, or longer where we decide an account needs it, a person on our trust and safety team reads each new kind of message from a number linked to a registration, or a toll-free number verified through our form, before it is sent, and approves or rejects it. To group messages into kinds we compare their text with names, numbers, amounts, email addresses and links masked; that comparison is fixed rules, not AI. A kind the classifier above could not place, or refused, is listed for our team the same way, at any age of the account. Held messages wait at most 3 days. For each kind we keep up to 320 characters of its first message with our decision. Our reviewers see the text and the sending registration, not the recipient's number.
  • Spotting the same message on many numbers. For live messages from a number linked to a registration, we keep, for 3 days, a fingerprint of each message's wording (a hash, made with names, numbers and links masked, never the text itself) and the number that sent it, so we can notice one message spread across many numbers or accounts. Fixed rules, not AI; a person on our team reviews what they flag.
  • Opt-out detection. An inbound reply that is not an exact keyword may be checked by rules and, if still unclear, by a third-party AI classifier to decide whether it revokes consent (for example "please stop texting me").
  • Complaint detection. Inbound replies are checked by fixed rules (not AI) for complaints ("spam", "who is this", "I never signed up", "reported", "wrong number"). We keep that a complaint happened, about which number, and a one-way hash of the person, never the reply's text; a "wrong number" reply is also treated as an opt-out. Complaint rates feed the enforcement steps in the Messaging Policy §9.
  • Features you turn on. If you enable an AI-powered feature, it processes the content it needs to do what you asked, and we will say so where you enable it.

Three features use AI on something other than messages:

  • TextKit Agent. The console's assistant ("Ask anything") answers questions about our documentation. When you ask it something, a third-party AI model receives your question, the earlier questions and answers in the same conversation, the address of the console page you asked from, and the parts of our public documentation that match. It never receives your messages, recipients, contacts, numbers, keys, or anything else from your account, and it cannot see or change them. We do not store the questions or answers: the conversation is kept in your browser, and signing out clears it. Answers can be wrong; the panel says so.

  • Filling in a registration from your website. When you ask us to, we read the public pages of the website you give us and take your business details from them with fixed rules. Where AI drafting is available, a third-party AI model also reads the text of those public pages to draft a description and suggest your industry; the form says so before you use it. In the console that is all it does: you choose what you send and write your own example messages. If you ask through the API, it can also suggest a use case and write draft example messages. The model receives only that public page text. It never receives message content, recipient data, or anything else from your account. Everything it drafts is a suggestion for you to review: drafted example messages stay marked as drafts and are never filed until you edit or confirm them, and nothing is filed until you submit. The toll-free verification form reads your website the same way; where AI drafting is available the model there also reads your privacy policy and terms to find your legal name, address, tax ID and nonprofit status (each kept only if those pages state it word for word), filled in for you to check before you submit. What you send, its description and example messages are never filled in from your website there: you write them.

  • Reading the carriers' answers about your toll-free verification. The carriers answer a toll-free verification form by email. We read each answer with fixed rules first. Where those rules cannot tell what it says, a third-party AI model reads the new part of that email (never the earlier messages quoted below it, which hold your form, and nothing else from your account) and suggests whether the number was verified, sent back, or is still in review. Its suggestion never changes your verification by itself: a person on our team reads it and records the verdict.

  • Checking your toll-free verification form before you submit. When you submit a toll-free verification form in the console, we first check whether its answers match each other and your business: fixed rules (including the links in your recent texts, which are checked by those rules only), then a third-party AI model that compares your form's answers (never your tax ID or the contact's phone and email) with the public text of the website on the form. What it finds is shown to you as advice; it never stops you from submitting, changes your form, or is kept.

A related tool uses no AI:

  • A texting plan from a website. Our public plan page reads the public pages of the website someone enters and suggests which texts the business could send, when, and draft wording, using fixed rules only, with no AI. The drafts are ours, marked as drafts, and are never filed for anyone.

Neither we nor our AI providers use your message content, the website text read for registration suggestions, the carriers' emails about your toll-free verification, your toll-free verification form, or your questions to TextKit Agent, to train or fine-tune general-purpose AI models. Our AI providers process it only to return a result to us, under terms that prohibit training on it. We will not train our own models on message content unless you opt in.

5. Sharing and Subprocessors

We share data only with:

  • Service providers (subprocessors) that help us run the Service: telecommunications carriers, aggregators, and campaign registries (which necessarily receive numbers and content to deliver messages); cloud hosting and database providers; our payment processor; AI moderation and classification providers; a phone data provider (for lookups); email delivery; product analytics (website and console analytics with consent, plus account-level usage metrics for business reporting; never message content or recipient numbers); and internal operations tooling. The Subprocessors page lists each category, what it does, and where it processes data.
  • Apps you connect. When an admin approves an app's connection to the account (for example an AI assistant), that app can read and change account data through the API, as the people using it direct. The app's own terms and privacy policy govern what it does with that data. Nothing is shared with an app you have not connected, and revoking its key ends its access.
  • Carriers and authorities, when needed to investigate abuse on the network or comply with law.
  • A successor in a merger, acquisition, or sale of assets, under this policy.

Carriers may also process message content under their own legal obligations.

6. SMS Opt-In Data and Mobile Information

No mobile information will be shared with third parties/affiliates for marketing/promotional purposes. All the above categories exclude text messaging originator opt-in data and consent; this information will not be shared with any third parties. Mobile information is never sold or rented. Delivering a text necessarily passes the recipient's number and the message to the carriers that route it; that is delivery of the message, not sharing of opt-in data or consent. Message recipients can revoke consent at any time by replying STOP, and can reply HELP for assistance.

7. Legal Requests

We disclose data in response to subpoenas, court orders, and warrants only when they are valid, and we require a warrant (or its equivalent) for message content, except in an emergency involving risk of death or serious physical injury. Where the law allows, we notify the affected customer first. See Terms §7.

8. Cookies and Analytics

The website and console use strictly necessary cookies for sign-in and security, including one that recognizes a browser you have signed in from, so that a sign-in from a new one can be reported to you. Product analytics (the pages you view, and the website or integration listing that first referred you to us) run only with your consent where the law requires it, and you can change your choice at any time on Privacy Choices. With the same consent we record visits to the website and console (what the page showed, clicks, scrolling and navigation) so our team can replay them to find what is confusing or broken. Recordings mask everything you type and every word inside the console, so they never contain your API keys, passwords, messages, phone numbers or contacts. They are kept on our own systems, seen only by our staff, and deleted after 30 days. We do not use advertising cookies.

Separately, our servers send account-level usage metrics to our product analytics provider for business reporting: your account identifier, how you signed up, when your account first sent a message in test and live mode, hourly counts of messages sent, delivered, and failed (and of segments sent) in each mode, and estimated charges at our published rates. They also show when your account buys a number (only whether it is toll-free or local, never the number itself), submits a toll-free verification or an A2P 10DLC registration (which of the two, and whether it is a resubmission), and has one approved (which of the two). To measure delivery rates we may also send, for each message, our internal message identifier, your account identifier, whether it was a test or live message, whether the carrier accepted, delivered, or failed it (with our failure category), the destination carrier's name, the segment count, and the customer identifier you assigned in our API, if any. These are counts, timings, and delivery status about your account's traffic. They never include message content, recipient or sender phone numbers, or any data about the people you message, and they set no cookies on your devices.

9. Your Rights

Depending on where you live (including under the GDPR and UK GDPR, and the privacy laws of California, Colorado, Connecticut, Virginia, Texas, Oregon, and other US states), you may have the right to access, correct, delete, or port your personal data, to restrict or object to processing, to opt out of sale, sharing, targeted advertising, or profiling, and to appeal our decision on a request. We honor these rights without discrimination.

  • Customers: email privacy@joinsimplesms.com. We log every request with the date we received it, verify it, and respond within the time the law requires (generally 30 to 45 days). You may use an authorized agent. You can delete or redact a single message yourself through the API. To have everything deleted, the account owner can also close the account in the console (Settings); Data Retention says what is deleted and when.
  • Message recipients: because the business that texted you controls that data, email privacy@joinsimplesms.com with the number that texted you and we will pass your request to that business and help it respond. To stop messages right away, reply STOP.
  • People who got a verification code by email: the business named in the email controls that data. Email privacy@joinsimplesms.com from the address the code went to, with the business's name, and we will pass your request to that business and help it respond, including deleting the address from its account.

10. Retention

We keep data only as long as we need it for the purposes above. The Data Retention page lists the periods for each kind of data, including message content, opt-out records, and closed accounts.

11. Security

Data is encrypted in transit with TLS and at rest. API keys are never stored in plain text: we look them up by a keyed hash under a secret held on our servers, and keep each active key encrypted under a separate key held on our servers, so your account's admins can view it again in the console. Every view is recorded in your account's audit log, and revoking a key deletes its encrypted copy. Verification codes are stored only as hashes, salted with their record identifier. Access to production systems is limited to personnel who need it and is logged. We notify affected customers of a personal data breach without undue delay, and within 72 hours of confirming one where the DPA applies. More in our security documentation.

12. International Transfers

We are a US company and process data in the United States. When we receive personal data from the EEA, UK, or Switzerland, we protect it with the safeguards in the DPA, including the EU Standard Contractual Clauses and the UK Addendum.

13. Children

The Service is for business use and is not directed to children under 16; we do not knowingly collect their data.

14. Changes

We will post changes here and, for material changes, notify account holders via the console or email before they take effect.

Contact

Truelabel Inc (d/b/a TextKit), a Wyoming corporation based in Nashville, Tennessee. Registered office and mailing address: 5830 E 2nd St, Ste 7000, PMB 35111, Casper, WY 82609, USA. privacy@joinsimplesms.com