# Privacy Policy

Source: https://jointextkit.com/privacy
Index: https://jointextkit.com/llms.txt

**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](/dpa). 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](/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](/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](/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](/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](/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](/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](/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](/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](/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](/dpa) applies. More in our [security
documentation](/docs/security).

## 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](/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