Privacy Policy

Scope and feature status

This policy applies to aramingoagency.com, inquiries submitted through it, and authenticated Aramingo tools. Creator management services are also governed by each creator’s signed management agreement and onboarding terms. Descriptions of conditional features explain their data path if they are enabled; they do not promise availability or activate those features.

On the production website, Creator Studio and the Team Portal work only after the agency Owner switches them on. Creator Studio is then open only to Creators the Owner adds to a Creator Studio access list; a Creator who is not on that list and proves who they are at sign-in is told that Creator Studio is not open to them yet, and no session is created. For this list, D1 keeps each listed Creator’s internal account ID, an internal reference to the Owner who added them, and when, until the Owner removes them, plus a history of each addition and removal with the same details, which has no automatic deletion schedule. The Team Portal is open to everyone with a Team grant (the Owner, Admins, Team Leaders, and Team Members), with the same role permissions described in this policy. Where this policy, including its storage table, describes the following as working on exact private staging, they also work the same way on the production website: Creator and Team sign-in, including passwords, email sign-in links, Google sign-in, passkeys, and two-step verification; password-reset, sign-in email change and transfer, security, and first-sign-in welcome emails; Creator accounts, including their creation by staff in the Team Portal, deactivation, Creator Profiles, Creator Information, and onboarding answers and their import; Creator Shared Drive uploads, staff sends to a Creator’s Drive folder, the Creator’s Google Drive content folder and its sharing controls, and the weekly pay-records copy to Google Drive; staff notices of Creator Drive uploads, the Owner’s Drive access reminders as in-app notices and emails, and the Owner and Admin email alerts for Drive uploads and Drive access notices; Custom Requests and their in-app notices and email alerts; the time clock, planned shifts, and Work History; the Agency Calendar and its notices and emails, while the calendar is switched on; Team checklists, per-account Team areas, the Owner’s account and staff rosters, and role changes; Documents & Links for Team accounts and Creators; the Owner’s record of emails the site sends, including Resend delivery, bounce, and complaint records and the resulting email suppression list; the business inquiries inbox; account notifications; the Owner’s payment QR images and their display to Creators; What’s New notes, which appear only after the Owner publishes each one; and Leak-Trace, saved credit, saved watermark, and Trailer Maker presets and background images. The following also work on the production website as this policy describes them, but each stays off until the Owner connects it by adding its credentials and switching it on: the Twitch connection and the Twitch Bot, including its chat features, stream tools, chat filters and raid shield, milestones, raid train, growth stats, and clips; Streamer.bot, including replay uploads; OBS overlays; the Owner’s Discord alerts, including Custom Requests alerts and the business alerts (business inquiries, FreshBooks invoices that became overdue or were paid, and sponsor reports), and, once the Owner also switches on alerts that involve people, Creator-activity and security alerts (including Drive access reminders and the new-device sign-in alert) and the new-device cookie; automatic caption transcription in Caption Studio, for Creators and for the agency Owner and Admins only, never for Team Leaders or Team Members; the Owner’s view of the agency’s GitHub pull-request history, which reads pull request titles and status from GitHub when the Owner opens it and stores nothing in Aramingo’s database (a short-lived copy kept in memory may be shown if GitHub is briefly unavailable); the FreshBooks connection, with the invoice information, history, and re-checks read from it for the Owner and for each mapped Creator’s billing card; and FreshBooks invoice reminder emails, which also need that connection and their own production switch. Everything else this policy describes as working only on exact private staging stays off on the production website, including the creator Discord bot.

Adults only

Aramingo Agency works exclusively with adults aged 18 or older. We do not knowingly collect inquiry information from anyone under 18. If you believe a minor has submitted personal information, contact us so we can address it.

Contact inquiries

When you submit the website inquiry form, your browser sends Aramingo your name, contact email, selected service, message, confirmation that you are at least 18, and any business or social handle you choose to provide. Aramingo stores the name, contact email, optional business or handle, service category, and message in its Cloudflare D1 database, with an internal inquiry identifier, source, status, and operational timestamps. The shared Business inquiries inbox is available only to authenticated, currently authorized Owners and Admins. On the production website, that inbox opens only when the Team Portal does; until then, stored inquiries cannot be viewed in the Team Portal, and the email copy described below is still sent. Inquiry handling stores purpose-keyed digests for bounded abuse and replay controls, not raw IP addresses; ordinary hosting and security processing is described separately below. To stop spam and repeated sends, each submission updates short-lived counters that store only keyed one-way hashes made with a server secret, never the raw value, with a count and a time window: for the sender’s IP address in 15-minute windows; for the sender’s network (the IPv4 address, or the IPv6 /64) per hour and per day; for the contact email entered, per day; and, written only after the inquiry is stored, a marker made from the contact email together with the selected service, business or handle, and message, so the same message sent again that day is answered as sent but kept once. Each counter is kept for the length of its limit window (15 minutes, an hour, or a day) and at least 30 minutes more, and is then deleted, up to 100 at a time, the next time someone signs in or submits the form; when the site is quiet, a counter can stay longer. The counters are not linked to the stored inquiry and are used for nothing else. Where Cloudflare Turnstile is switched on, the form also runs the human check described under service providers. We also receive information you send directly to our business email.

For a newly stored website inquiry, Aramingo attempts one email copy through Resend to hello@aramingoagency.com. The copy includes the submitted name, contact email, optional business or handle, service category, and message. A replay of the same stored inquiry does not trigger another copy. A failed notification does not undo the stored inquiry, and an accepted email-send result does not prove inbox delivery or that anyone read it. On exact private staging and, once the Owner connects Discord alerts, on the production website, the existing Owner-controlled business alert may also tell the agency’s private Discord channel only the inquiry category, never the name, contact details, handle, or message; the email copy is sent separately and does not depend on it. Unconfirmed submissions are not automatically resent.

The contact form keeps entered fields, a short-lived sealed form token, and an unresolved identical-retry body only in the mounted page’s memory; it does not write them to localStorage, sessionStorage, cookies, IndexedDB, or Cache Storage. A confirmed success clears the draft and retry state, and leaving the form clears its component state. An unconfirmed attempt keeps the fields for an explicit identical retry while the form remains open. A no-script result redirects with only a fixed result label and starts a blank draft; no inquiry content is placed in the redirect address. Same-origin requests may still carry existing session cookies. These statements describe the form, not all browser storage used by the website.

An inquiry, social handle, or creator profile may reveal personal details. We do not need payment information, government identifiers, account credentials, private media, health information, or other highly sensitive information for an initial inquiry. Please do not send it. Enter Studio credentials only on the Studio sign-in page. If you voluntarily provide sensitive information relevant to an inquiry, we use it only to review and respond and limit access to people who need it for that purpose.

Visitor preferences and browser storage

The public site uses eight first-party localStorage keys for theme, font, soundtrack on/off, soundtrack volume, top-bar follow behavior, visual effects on/off, visual effects scope, and visual variant, and one more for a dismissed site announcement, described below. These preference values are not included in an inquiry. The replacement contact form does not use the older inquiry cooldown timestamp; a timestamp left by an earlier page may remain until that browser session ends.

The agency Owner can post a short site announcement, written by staff, that appears as a banner on any of the public website, Creator Studio and the Team Portal that the Owner chooses, between a start and an end time no more than 90 days apart. Announcements contain no visitor information. D1 keeps the current announcement, with the internal staff reference of the Owner who last saved or ended it, a version number and when that happened, until the Owner replaces it; ending an announcement early stops it showing but keeps it until then. Each save and each early end also adds a record of the message, where it shows, its times, whether visitors can dismiss it, its version, the Owner’s internal staff reference, the action and when it happened; these records cannot be changed and are deleted after 400 days. When the Owner lets visitors dismiss an announcement, dismissing it keeps only that announcement’s version number in that browser’s localStorage, so it stays hidden there until the Owner saves a new version; the dismissal is not sent to Aramingo, and clearing this site’s browser data removes it.

When server-backed preference storage is configured, the site may also keep theme, font, soundtrack, volume, top-bar follow, visual effects, and effects-scope settings in D1. The record is keyed by an HMAC-derived identifier made from the request’s public IP address; the preference table does not store the raw IP. People sharing a public IP may therefore share those server-backed settings. The visual-variant choice remains browser-only. If D1 or its hashing secret is unavailable, the browser-local settings continue as the fallback. Saving preferences is also limited per IP address and for the whole site in 15-minute windows; those counters store only a keyed hash of the IP address, or a fixed site-wide key, with a count, and are deleted the same way, at least 30 minutes after the last save they counted.

The public site has no cookie-consent banner because it does not set advertising or analytics cookies or use advertising pixels. On the production website only, the public pages (the home page, What’s New, Privacy, and Terms) load Cloudflare Web Analytics, a script from Cloudflare that measures page views and how quickly pages load. When such a page loads and when you leave it, your browser sends Cloudflare the page address without its query string, the address of the page that linked to it, and page-timing measurements, and Cloudflare also receives the details any web request carries, such as the IP address and browser type. Cloudflare says Web Analytics does not use cookies, localStorage, or other browser storage, and does not identify visitors by fingerprinting their IP address or browser. Aramingo sees only Cloudflare’s aggregate reports, such as visit counts, popular pages, referring sites, countries, and device and browser types; Cloudflare keeps detailed records for 7 days and aggregated reports for about six months. Signed-in areas, error pages, and private staging do not load it. Functional browser and server storage, including the conditional browser-local AI model cache, is described below.

Aramingo uses Google Search Console to see how the public website appears in Google Search. Aramingo proves that it owns the domain with a DNS record, not with code on the website, and the website sends Google nothing about its visitors for this. Google gives Aramingo aggregate reports built from Google’s own search data, such as the search terms that showed the site’s pages, with their clicks, impressions, and positions, under Google’s privacy policy.

Creator Studio accounts and media

Creator accounts are created manually by authorized Aramingo staff for agency clients; there is no public self-registration flow or invitation-token account creation. An account record may include an internal ID, username, separately supplied first and last names, a chosen display name, optional contact email and normalized email, role, active or disabled status, a password hash, temporary-password-change state, created and updated times, password-change and last-sign-in times, and the verified staff identifier that issued it. Staff who can see the Creator accounts list in the Team Portal can also see each Creator’s last sign-in date. Existing records may not have separate first and last names. Aramingo does not store a readable password.

A successful Creator sign-in creates the __Host-aramingo_creator cookie for up to 12 hours. Creator sessions expire after 12 hours unless sign-out, Sign Out of All Devices on Profile Settings, account disablement, an Owner recovery action, or certain credential changes revoke them sooner. Sign Out of All Devices ends every session of that Creator account, including the current one, and writes a security audit record of when it happened. The cookie is HttpOnly, Secure, SameSite=Strict, Path=/, and has no Domain attribute. D1 receives only a hash of the random session token, the Creator ID, and creation and expiry times; the raw token remains in the cookie.

Creator sign-in methods and security records

Password sign-in is the current fallback. Creator Google sign-in and linking, and Creator passkey registration and sign-in, are implemented but require valid runtime configuration and are not described here as active without that proof. If a Google identity is linked, Aramingo stores the provider name, Google subject, normalized verified email, verification/link/sign-in times, and any revocation time. If a passkey is registered, Aramingo stores its credential ID, WebAuthn user ID, public verification key, signature counter, transports, device type, backup state, optional label, and lifecycle times. Aramingo never receives or stores the passkey’s private key.

On exact private staging and on the production website, when its separate email configuration is valid and enabled, an active staff-issued Creator account may request a one-time email sign-in link or password-reset link. Repeated unsuccessful sign-in attempts may also trigger an advisory security notice. These emails do not create accounts, bypass required MFA, or guarantee inbox delivery. A sign-in or reset bearer link stops authorizing after at most 10 minutes or use. D1 stores hashes of these tokens, the Creator ID, normalized account email, issue/expiry/use times and bounded security metadata—not readable bearer links or message bodies.

Configured Creator sign-in methods use short-lived security records and bounded operational records. Passkey and primary-MFA challenges are logically valid for up to five minutes and D1 stores a challenge hash, purpose, optional Creator ID and primary method, timestamps, and an optional keyed IP derivative. Rate-limit rows store keyed derivatives of usernames, internal subjects, emails, IP addresses, or IP networks (an IPv6 address is counted by its /64 network) plus a time window, count, and update time. Besides the sign-in limits, they cap how many sign-in-link and password-reset emails one email address can request each day, and how many invitation and sign-in email change emails one staff member can send in 15 minutes and in a day. Security audit rows contain a bounded event ID, actor kind and identifier, event type, optional target Creator ID, and time. They do not contain passwords, raw session tokens, raw recovery codes, raw IP addresses, or Creator media.

Administrators and creators may enroll a compatible authenticator when that protection is configured. Aramingo stores an encrypted authenticator secret with its initialization vector, lifecycle times, the last accepted time step, and keyed hashes of single-use recovery codes. The setup secret is displayed during enrollment, recovery codes are displayed only once, and Aramingo does not retain readable copies. An unfinished enrollment is logically valid for ten minutes.

Administrator and Owner access

Administrator and Owner access is based on a verified Aramingo Google Workspace identity and Aramingo’s exact email allowlist. Google controls the Workspace account and Google password. Aramingo verifies the signed Google subject, email, verified-email flag, and hosted Workspace domain, then stores the verified subject and email with a hashed administrator session token and timestamps. The designated Owner may also be required to prove a separate agency recovery password; only its configured hash is used. The designated agency security owner may issue a temporary Creator password or perform bounded recovery actions. Aramingo does not store the Google password.

Administrator access creates the __Host-aramingo_admin cookie for up to eight hours. It is HttpOnly, Secure, SameSite=Strict, Path=/, and has no Domain attribute. Removing an email from the allowlist blocks that identity on its next request; sign-out and security recovery can revoke its sessions.

The site does not use a CSRF cookie. Authenticated mutation routes use same-origin validation, the Strict session cookies, and endpoint-specific fixed mutation headers where defined.

Team Portal

The Team Portal uses Google sign-in, four role dashboards, invitation-managed staff access, and Team session handling. Team authentication, sessions, and changes fail closed unless the request is for Aramingo’s exact private staging host or, once the Owner switches the Team Portal on, the production website, and the activation and identity configuration for that site are valid. A sign-in requires a verified Google identity and current server-side authorization; there is no self-registration or role selector. Allowlisted Owner and Admin identities remain subject to the existing administrator controls. A non-allowlisted ordinary Admin must also present Aramingo Workspace proof, hold an active Admin grant, and complete valid MFA; a Team Leader or Team Member must hold an active staff grant. D1 may store an internal staff-principal identifier, Google provider subject, active or disabled status, privileged role or normalized-email access grant, separately supplied first and last names on new staff or ordinary-Admin grants, role, authorization and record versions, principal links, lifecycle times, and bounded grant audit records. Older grants may have no separate names. Access changes are attributed through internal staff-principal identifiers.

When the Team Portal is switched on and Team sign-in succeeds, Aramingo sets the __Host-aramingo_team cookie for up to eight hours. It is HttpOnly, Secure, SameSite=Strict, Path=/, and has no Domain attribute. Its AES-256-GCM-sealed state contains an internal staff-principal identifier, role, authorization version, verified Google subject and normalized email, derived display name, issue and expiry times, and an Owner step-up time when applicable. Each use is revalidated against current principal and grant authorization; there is no separate Team-session database row. A first ordinary-Admin MFA enrollment may also set __Host-aramingo_team_mfa for up to ten minutes with the same cookie attributes. That cookie contains sealed pending principal, authorization, verified Google identity, display-name, and timing state and is cleared when enrollment completes, expires, or restarts.

Clock Time And Planned Shifts

On exact private staging and the production website, when the protected work-time dataset is admitted, a Team Member or Team Leader can clock in and out and read their own actual-time history. Clock times come from the server, not a browser-supplied time. Actual time is separate from planned shifts. A Member sees their own planned shifts; a Leader can also see authorized Members’ planned shifts. Admins and the Owner may read authorized planned shifts. The Owner may create planned shifts for an Admin, Team Leader, or Team Member, an Admin may create them for Team Leaders and Team Members, and a Leader whom the Owner has designated may create them for authorized Members; that designation does not permit creating their own shift, changing existing times, or correcting actual clock records. Only the Owner may change existing planned times, correct actual records, or designate and revoke scheduling permission. Individually delegated Calendar viewing does not grant these powers. This feature is not a payroll or billing system, although weekly hours summaries may be kept as pay records as described below; it collects no location or biometric data.

D1 keeps internal staff and record identifiers, the original observed clock-in and clock-out times, current effective times, versions, and open or closed state. An Owner correction preserves the original observation and records the before-and-after times, a fixed reason, the correcting Owner, and when it was recorded; it does not pretend a missed clock-out was observed. Planned shift records hold the assigned and creating staff references, UTC start and end, IANA time zone, state, versions, and lifecycle times. Separate records hold the designated Leader, their current authorization evidence, the Owner who changed permission, and the designation history state, plus minimal mutation receipts, action audit records, and provider-sync state. These are protected pseudonymous records, not anonymous information. The browser receives authorized labels, times, state, and short-lived opaque action handles, not internal principal identifiers, credentials, or provider responses. Clock and shift data is not saved in browser storage.

If the existing Agency Team Calendar is configured and enabled, a bounded scheduled job mirrors planned shifts to that agency-owned private Google Calendar. This is separate from the general Creator and staff calendar events described below: planned shifts and their synchronization records are stored in D1. Google receives only the scheduled start and end, time zone, internal shift and staff ownership references, an opaque event identifier, revision, and scheduled or cancelled state, under a fixed Team Shift title with no description or attendees. Original or effective actual clock time, corrections, correction reasons, and Leader designations are never sent to Google. A saved shift is not a claim that Google has synchronized it; pending, conflict, and unavailable states remain visible. Uncertain provider writes are reconciled by reading, not blindly sending them again. Google-side events have no automatic deletion schedule in this feature and may remain after application visibility expires. Neither this notice nor assigning a menu item enables the Google integration or sends invitations, reminders, or notifications.

Closed actual records and their correction bodies stop appearing 90 days after the effective end; ended planned shifts stop appearing 90 days after their end, and cancelled shifts 90 days after cancellation. Minimal mutation and staff-action audit records become eligible for cleanup after 180 days; obsolete settled synchronization evidence after 30 days. Scheduled cleanup deletes at most 100 eligible rows per sweep, with children removed before their parents. These are eligibility and visibility rules, not a guarantee of physical deletion at the exact deadline. An open clock is not automatically closed or deleted. Current operation receipts, unresolved or possibly dispatched provider work, current provider references, and live dependencies remain pinned until safely resolved, even beyond those periods. Minimal erasure and replay fences are retained for at least 32 days and are extended when bodies are actually removed so that an old backup cannot restore them. Encrypted database backups may retain earlier copies on the separate backup schedule below; restoring one does not reactivate old scheduling designations or bypass current erasure and replay evidence.

Before their first clock-in, each Team staff member confirms their time zone once; it is the same time zone their Team calendar uses, and they cannot change it afterward. Only the Owner can change it, and the change takes effect at the start of the next pay week (Friday at 00:00 in the time zone then in force). Work history shows a person’s clock-in and clock-out times by pay week, from Friday to Thursday in their own time zone, with daily and weekly totals. A staff member can see their own work history; the Owner can see any Team staff member’s; an Admin given Work History access can see Team Leaders’ and Team Members’, but not the Owner’s or another Admin’s; and the Owner or an Admin can assign one Team Leader to each Team Member, who can then see that Member’s work history and that Member’s clock times on the Team calendar. People other than the Owner see only the effective times; the before-and-after details of an Owner correction remain visible only to the Owner. Each time someone views or downloads another person’s work history, or their clock times on the Team calendar, Aramingo records who did it, whose history it was, which week or calendar window, and when, before anything is shown, and refuses the view if that record cannot be written; the record contains no clock-in or clock-out times. D1 keeps each person’s time zone as dated periods (the time zone, whether they confirmed it or the Owner changed it, who set it, and when) and each Team Member’s assigned Team Leader, and records each time-zone change and Leader assignment with who made it and when. A scheduled cleanup removes viewing and download records after 90 days, and time-zone and Leader-assignment records after 400 days; an older time-zone period is removed once no kept clock record depends on it. A Team account that is disabled or whose role has changed loses this access. Restoring a backup never brings back a removed Leader assignment or a replaced time-zone change.

Where enabled on exact private staging and the production website, after each pay week ends Aramingo saves a spreadsheet file (CSV) of each staff member’s hours for that week to a separate shared drive in the agency’s own Google Workspace that is used only for these pay records: a name label, the dates, the clock-in and clock-out times, and daily and weekly totals, without account IDs or email addresses. Only the agency Owner and a system account that Aramingo uses only to save and delete these files can open that drive, although the agency’s Google Workspace administrators can technically reach any of its drives; before each save, Aramingo checks that no one else has been given access and saves nothing if anyone has. These copies are kept as pay records for three years, then deleted automatically and removed from the drive’s trash within 30 days, even though the clock records in Aramingo’s database stop appearing after 90 days.

When the authenticated Team checklist is enabled on exact private staging and the production website, authorized staff can create and rename tasklists and create, edit, reorder, complete, and undo tasks for themselves or for an opaque target that Security authorizes as having a strictly lower role.

For that conditional feature, Aramingo’s D1 database stores tasklist titles, task labels, optional notes, sort order, optional schedule mode, IANA time zone, due or occurrence times, completion and undo state, bounded record versions, and timestamps. It also stores completion occurrences and mutation audit records. Those operational records use internal opaque identifiers for the staff actor and checklist owner, the relation self or lower role, action and resource identifiers, and the occurrence time.

The Team checklist interface and routes do not expose internal actor or owner principal IDs, provider identity details, Team session or MFA state, access-grant data, raw D1 diagnostics, or audit history. Lower-role targets are shown with Security-generated pseudonyms, not real names.

Version 1 provides no delete, archive, template, reminder, or notification operation, so the underlying tasklists and tasks have no user-facing deletion control. Completion-occurrence history and checklist audit history have a 400-day cleanup target, but cleanup is best effort and runs only during later qualifying mutations. Each qualifying mutation can remove at most 50 completion-occurrence rows and, independently, at most 50 checklist audit rows; these are separate caps, not a 50-row combined limit or a timed deletion guarantee. Purging checklist data for a disabled staff principal is a separate dependency-ordered Platform operation, not an automatic Team interface action.

On exact private staging and the production website, authorized staff can manage which Team Portal areas an individual Team account may access. Aramingo’s D1 database keeps the account’s versioned assignment set and area entries, internal opaque staff-principal references, and related lifecycle and authorization state. Assignment changes create separate mutation audit events. The assignment set and entries are active access state without a timed expiry; resetting access clears the entries but retains the versioned set. Audit events have a 400-day cleanup target that runs only on later qualifying mutations and removes at most 50 old rows per mutation. This is best-effort cleanup, not a guarantee of deletion on a particular day. An individually assigned Team Leader or Admin may view a read-only cached Owner invoice list with Creator display names, lifecycle and sanitized invoice status, dates, amount and currency; older connected snapshots appear as stale, and unavailable data does not mean nothing is owed. The assigned invoice read does not refresh FreshBooks, provide lifecycle-action evidence, or authorize connection, mapping, or account lifecycle changes. A separate assigned read-only Payment QR view may show existing QR images, but cannot upload, remove, or change them. Direct access is rechecked and revocation closes it. The per-account assignments remain subject to server-side role and authorization checks.

On exact private staging and the production website, the Owner may upload a payment-method QR image to a private R2 bucket. D1 keeps bounded asset metadata including the internal asset and method identifiers, content type, byte size, dimensions, checksum, revision, state, and lifecycle times. An eligible individually assigned Admin or Team Leader may view the active method, bounded image metadata, and private preview through read-only Team routes with fresh access checks; only the Owner may upload, replace, or remove an image. Signed-in Creators can view the active payment QR images on the billing card in Creator Studio, even while FreshBooks is unavailable. These are not public-site assets. Removal and replacement attempt guarded cleanup, but there is no fixed physical-deletion guarantee. Viewing a QR image is not payment processing.

On exact private staging and the production website, an Owner-assigned eligible Admin or Team Leader may read the bounded Owner Account Status roster. That view includes Team account email addresses, roles and activation states, and Creator display names, usernames, contact email addresses when present, and activation states. The read-only response omits mutation handles and rechecks the recipient’s role, session, individual assignment, and assignment version before release. It grants no activation or deactivation authority; native mutations remain separate and retain Owner verification where required. Revocation closes future reads, not information already seen.

On exact private staging and the production website, an Owner-assigned eligible Admin or Team Leader may read a bounded Staff Access grant roster showing staff display names, email addresses, Member or Leader roles, and active or revoked grant status. The read-only response contains no grant or activation handles. Every read rechecks the recipient’s session, role, individual assignment, and assignment version; revocation closes future reads but cannot erase information already seen. This assignment does not authorize creating, changing, revoking, or activating staff accounts. Those mutations remain under their existing role and Owner-security boundaries.

On exact private staging and the production website, the Owner may separately assign the Admin Role Changes variant to an eligible Team Leader account, or revoke an ordinary Admin’s native Role Changes access independently of Staff Access. An assigned Leader can view bounded active Team Member and Team Leader grant display names, email addresses, and roles, and change an existing Member to Leader or Leader to Member using the current grant role and authorization version. A role change creates a bounded audit event attributed through internal staff-principal references. The assignment does not grant Leader account creation, grant revocation, Admin or Owner role changes, or Owner authority. Every direct action rechecks the recipient’s session and exact assignment, and a versioned database guard closes in-flight role changes after revocation. Existing staff-grant and audit retention terms still apply.

When the clock-correction request workflow is enabled in Team Portal, a Team Member or Team Leader can ask for a correction to one of their own eligible clock entries, giving the requested start and end times and a reason of up to 500 characters. Their Team Leader, or the agency Owner for someone without one, confirms or rejects it, and only the Owner approves or rejects a confirmed request. D1 keeps the entry reference, original and requested times, reason, status, internal staff references for confirmation and decision, the deciding role, versions and timestamps, and any acknowledgement that the week’s Work History copy was already saved. The requester sees their own requests, their Team Leader sees their Team Members’ requests, and the Owner sees all of them; no email or Discord message is sent for a correction request. Approval changes the effective times and site totals while keeping the original times; it does not change a Work History copy already saved to Google Drive. The request is deleted with its parent clock entry under the work-time retention described above.

When staff offboarding is enabled in Team Portal, the agency Owner can offboard an Admin, Team Leader, or Team Member, and an Admin with Staff Access can offboard a Team Leader or Team Member after confirming with their two-step verification code; nobody can offboard the Owner or themselves. Offboarding revokes Team access, ends the person’s Team Portal sessions, and removes Creator Information assignments and editor grants, Team Leader links, all-Creators settings, and Documents & Links shared only with that person. Offboarding does not change Google Drive sharing; the Owner removes the person’s access to the agency’s shared Drive folders in Google Drive. Stored menu assignments can remain but no longer grant access at the revoked authorization version. Open custom requests can be reassigned to the departing person’s Team Leader, keeping their original submitter, or flagged for the Owner. D1 records internal references to the departing person and their former role, the acting staff member and role, any reassignment Leader, an operation reference, counts of affected records, and versions and timestamps. These references can be linked to staff accounts; they are not anonymous, but the offboarding record contains no names or free-text content. The Owner and Admins with Staff Access see past offboardings as counts, roles, and times, not those internal references. Records become eligible for bounded scheduled cleanup after 400 days; delayed or failed cleanup can leave older rows until a later successful pass.

The agency Owner can also view an access log in the Team Portal showing who viewed Creator Information, Work History (including its CSV downloads), custom requests, onboarding records (including searches), and the Owner’s notes. It shows the view records described elsewhere in this policy and keeps no records of its own, so it reaches back only as far as those records are kept: 90 days for Work History views and downloads, and 400 days for the others.

When the access-review workflow is enabled in Team Portal, the agency Owner and Admins with Staff Access can review each active Team Leader’s and Team Member’s name, role, numbers of Creator assignments and editor grants, all-Creators settings, Team Leader links, assigned menu pages, and shift-planning access. Each quarter, an on-site notice reminds the Owner to review Team access. If reminder email is enabled and the Owner’s email alerts are on, Resend processes the Owner’s recipient address and a fixed reminder identifying the quarter and directing the Owner to Staff Access; it includes no staff names, access roster, or record-bearing link. Email acceptance does not prove delivery. D1 keeps the quarter, creation and acknowledgement times and acknowledging staff reference, plus email status, attempt, retry, and lease metadata. Reminder rows become eligible for bounded scheduled cleanup after 732 days (about two years), rather than guaranteed immediate deletion. Existing transactional-email history, provider processing, and retention terms below also apply.

When incident alerts are enabled in Team Portal, the agency Owner can choose which active Admins receive operational incident notices alongside the Owner. The Owner’s recipient list shows each Admin’s display name or sign-in email and current designation. D1 keeps the Admin’s internal staff reference, whether alerts are on, the current authorization version, who changed the setting, and operation, version, and timestamp metadata. Those references can be linked to staff accounts. No designation, an off setting, or an outdated authorization version does not authorize Admin alerts. The Owner remains a recipient. Each recipient can read and mark only their own notices, which contain a fixed incident category and message, occurrence time, and read state, not raw logs, stack traces, account names, email addresses, or Creator content. Categories cover operational failures, selected account-security events, and an email-send-limit notice.

Where the site’s Team Portal email is enabled, incident email is sent with it, with no separate switch, and Resend processes the Owner’s and currently designated Admins’ sign-in email addresses with the fixed incident message, under the transactional-email controls and retention described below; acceptance does not guarantee delivery. The email-send-limit incident is never emailed; it appears as an on-site notice and as the category-only Owner Discord alert described in this policy. Turning an Admin’s setting off excludes them from subsequent recipient selections. It does not recall notices or email already received, and an incident already being processed may still use its earlier recipient list. It does not change membership in the Owner’s manually managed Discord channel or third-party monitoring recipients. D1 notice records include recipient and incident references, creation and occurrence times, read state, and expiry; notices expire from the site after 90 days. Designation-change audit records keep the acting and target staff references, before and after settings, operation reference, and time, and become eligible for cleanup after 400 days. Current designation settings have no automatic expiry. Operational workflow-run deduplication records, containing a run reference, allowlisted workflow category, fixed outcome, and time, become eligible for cleanup after 30 days. Scheduled cleanup is bounded: backlog or failures may leave expired records until a later successful pass. These disclosures do not mean that an incident producer, email delivery, or a monitoring integration is active.

Conditional Standard Procedures

When Standard Procedures is enabled in Team Portal, staff can read visible procedures assigned to their current role. The Owner can create procedures, edit their titles, descriptions and Markdown text or HTTPS links, change role assignments, hide or remove procedures, and restore earlier contents. A hidden, removed or unassigned procedure is not available through the staff view. This describes conditional functionality, not a claim that the procedure pages or management controls are enabled.

D1 stores each procedure’s internal identifier, optional built-in key and order, title, description, text or link, visible, hidden or removed state, record version, creation and update times, and the updating Owner’s internal staff reference when applicable. It also stores role assignments and their times, the role matrix’s version, and earlier contents with their title, description, text or link, procedure version, save time and saving staff reference. Refreshing an untouched built-in procedure also saves its earlier contents, with no saving staff reference because it is a system change. Separate change events record the internal operation, procedure and acting staff references, action, affected role or before-and-after state, resulting version and time, plus a protected one-way request fingerprint used to recognize an exact repeat of a change; those events do not contain the procedure’s title, description, text or link. Internal references and request fingerprints are protected, linkable information, not anonymous information.

Hiding or removing a procedure is not erasure: its stored contents, role assignments and history remain recoverable. Procedure records and assignments have no automatic expiry; the 20 most recent earlier contents are retained alongside the current contents, and older versions are removed when another version is saved. The procedure store does not automatically erase updating or saving staff references; those references can remain with recoverable procedures and history. Change events become eligible for cleanup 400 days after the event, with at most 200 eligible events removed per pass. Bounded cleanup, backlog or failure can leave older events until a later successful pass; this is not an exact-time deletion guarantee. Database backups have the separate retention described below, so removing a version from active storage does not immediately remove an earlier backup copy. These statements do not claim that procedure storage, scheduled cleanup or recovery wiring has been activated.

Conditional Custom Requests

Where Custom Requests is enabled on exact private staging and the production website, a Team Member may select only a currently assigned Creator Profile and record a custom-content request, proposed price in USD, fan name, and fan username. Aramingo stores those four fields in isolated Cloudflare D1 together with the Creator Profile reference, submitting staff reference, server-recorded time, status, and record version. The Member can view their own requests; the currently assigned Team Leader and currently authorized Admins and Owner can review the authorized history and mark a request as sent to the fan, cancelled, or requiring negotiation. A disposition records the staff actor and time and stops overdue reminders. It does not send content to a fan, charge anyone, or prove a delivery. This is not a Creator-facing feature. Please do not put credentials, payment information, private media, health information, or other unnecessary sensitive details in a request. Drafts and unresolved identical-retry state stay only in the mounted page's memory, not persistent browser storage.

For a newly recorded request, Aramingo creates an in-app notice for the current authorized management audience and attempts generic email alerts through Resend and, where privately configured, Discord alerts to Owner-designated per-recipient channels. These external alerts contain only a fixed alert category and authenticated portal link, not the request text, price, fan details, Creator name, or chatter name. Resend receives the intended recipient email and fixed sender, subject, and purpose/template labels; Discord receives the bot/channel identifiers needed to send the fixed alert after current private-channel verification. A disposition creates an in-app notice for the still-authorized submitting Member, not an email or Discord alert to that Member. Pending requests trigger Admin/Owner reminders after 3 days, 7 days, and every further 7 days; a delayed sweep attempts only the latest elapsed reminder slot, not a backlog. Current authorization and email suppression remain enforced. Queued, accepted, delivered, and read are distinct states: provider acceptance proves neither inbox delivery nor reading, and uncertain sends are not automatically resent. Existing receipt-correlated email webhooks supply delivery history; recording a send does not invent a delivery event. Provider copies and logs follow the providers' own retention and are not recalled by a later portal erasure. On the production website, the Discord alerts for Custom Requests also work once the Owner connects Discord alerts and switches them on, using routes set up separately for the production website; a route set up on staging never opens on the production website.

An unresolved active request has no age-only detail expiry. The earliest disposition or Creator offboarding starts a 30-day deadline: all four protected fields stop appearing at that deadline and are physically cleared together by bounded cleanup. Approved source erasure can clear them earlier. Each cleanup pass processes at most 25 request bodies; separate passes process at most 25 audit rows, completed full operation receipts, expired site notices, settled deliveries, and eligible minimal request or operation references per family. Content-free audit events have a 400-day cleanup target. Completed full operation contexts and receipts retire after 30 days, or earlier with source erasure; retirement never confirms an unresolved save or releases its replacement lock. Unread site notices expire at 180 days; read notices at 90 days from the read change, capped by the original 180-day horizon, and source closure can end them sooner. Minimal references remain while required by an unresolved save, possible provider dispatch, or live dependency, even beyond those periods; otherwise cleanup removes eligible settled references after their respective 400-day horizon. Internal staff/Profile references, keyed fingerprints, sealed routing data, and minimal replay evidence are protected pseudonymous records, not anonymous information or a permanent second profile history. Cleanup targets are not exact-time deletion guarantees. Encrypted backups may retain earlier data for up to 30 additional days after physical source removal under the separate backup policy. An isolated restore re-applies current live erasure and read state, preserves unresolved locks and reminder/delivery fences, closes unverifiable recipient routing, suppresses old unsent alerts, and keeps possible sends uncertain rather than replaying them.

Conditional Creator onboarding answers

Conditional Creator onboarding answers may include sensitive race or ethnicity, sexual-orientation, or sex-life information from a historical Typeform CSV selected by an authorized Owner or Admin. The browser parses the selected local file; only one deliberately confirmed set of 28 answers and optional original submission-time text is sent to Aramingo's Cloudflare Worker and stored in its D1 database; the staging and production databases are separate. The file, Typeform token, source-row name hint, and unselected rows are not sent. An authenticated Creator may see and correct only their own linked answers; authorized Owner/Admin staff may review, correct, archive, or erase them with access evidence; and, where Creator Information is enabled, Team Leaders may also correct them and a Team Member assigned to the Creator may view them, as described under Creator Information. Cloudflare processes the application data as its hosting provider, and authorized recovery operators may handle protected backup copies under the separate backup policy. Signed consent and withdrawal evidence is kept outside the application. This is not an automatic Typeform import feature.

Creator Information

On exact private staging and the production website, the agency keeps a Creator Profile for each Creator, which can be linked to the Creator’s account. A profile holds the Creator’s onboarding answers described above, a profile name, an alias, a time zone, and two private notes that only the agency Owner can see. A linked Creator can see their own onboarding answers and content pricing on the My Information page in Creator Studio, but not the profile name, alias, or the Owner’s notes; their notifications page also shows their profile’s time zone, which their emails use unless they choose another; they can correct their answers and pricing, except the two original pricing answers, which are shown read-only. Archiving a profile unlinks it from the Creator’s account and follows the archive rules for onboarding answers above; erasing a profile clears its onboarding answers, profile name, alias, time zone, and the Owner’s notes.

Automated emails show dates and times in a time zone chosen for each account. A Creator can choose a time zone for their emails on their notifications page in Creator Studio; otherwise their emails use their Creator Profile’s time zone, or the website’s default if there is none. A staff member can choose a personal time zone, which their emails use unless they also choose a separate email time zone; this does not change the work-history time zone described in the Team Portal section. Each person can change only their own account’s time zones. D1 keeps each account’s chosen time zones, if any, with a version number and when they were last changed, for as long as the account exists. Each change also adds an account audit record of who made it, for which Creator if any, and when, without the time-zone values; these records are deleted after 400 days. Resend receives only the email itself, with its times shown in that time zone, as described for other emails.

A profile can also hold the Creator’s content pricing: prices for up to ten kinds of content from a fixed list, each in whole cents or left blank and each with an optional one-line note (up to 200 characters), and a free-text description of the Creator’s content limitations (up to 2,000 characters). The Creator can change their own pricing, the agency Owner and Admins can change any Creator’s pricing, and a Team Leader or Team Member can change it only with the editor grant described below; D1 records whether staff or the Creator made the last change, with an internal ID, and a version and the created and updated times. Pricing is kept until it is changed; archiving the profile keeps it until the archived profile itself is cleaned up, and erasing the profile deletes it. Each change is recorded with who made it, when, and which prices changed, but never the amounts or text.

The Owner and Admins can correct a Creator’s onboarding answers on the profile and change any Creator’s content pricing. A Team Leader or Team Member can change a Creator’s onboarding answers and content pricing only when the Owner or an Admin has given them an editor grant, either for that one Creator’s profile or for all Creators at once; an all-Creators grant also covers Creators added later and stops covering a Creator who is deactivated or leaves the agency, and a Team Member’s all-Creators editor grant comes with read access to all Creators. Team Leaders can read every active Creator’s profile name, alias, time zone, onboarding answers (including any sensitive answers described above), and content pricing, except the parts the Owner or an Admin has turned off for them in the Team Portal’s menu access settings. Team Members can read the same information only for profiles assigned to them (giving a Team Member editor access to a Creator also assigns that Creator), or for every active Creator if the Owner or an Admin has given them read access to all Creators. The Owner, Admins, and Team Leaders can assign a Creator’s profile to individual Team Members, and the Owner and Admins also manage assignments, all-Creators settings, and editor grants on a separate access page. No Team Leader or Team Member ever sees the Owner’s notes, and a Creator who is deactivated or has left the agency drops out of every level of staff access until reactivated. Each view is recorded with who viewed it and when before anything is shown, and the view is refused if that record cannot be written. D1 keeps each assignment and editor grant, with when it was made and by whom, and each Team Leader’s and Team Member’s all-Creators settings, until they are changed; unassigning or revoking removes them, archiving or erasing the profile removes its assignments and editor grants, and a disabled staff member’s, or a staff member whose role changed, gets no access from them. Each assignment, editor grant, and setting change is recorded with who made it, when, and the access level before and after. These view, access, and pricing-change records contain no answers, prices, or notes and are deleted after 400 days. Restoring a backup never brings back erased pricing, a removed assignment, or a revoked editor grant; encrypted offsite backups are kept for at most 30 days. This information is not sent to analytics or to outside services other than Cloudflare, which hosts the database.

On exact private staging and the production website, when a Creator updates their onboarding answers, content limitations, or pricing, the active Team Members assigned to that Creator and those Members’ active Team Leaders receive a notice on the Team Portal’s Notifications page, with an unread count in the menu. Each person sees only their own notices, which say which Creator and what kind of change, never the values, and which name the Creator only while that person may still read the Creator’s information. No email or Discord message is sent for these notices. At most one notice is created per person, Creator, and kind of change each hour. D1 keeps each notice’s recipient, the Creator profile, the kind of change, and read state, with no values. These notices cannot be turned off and are kept for 90 days, after which a scheduled cleanup deletes them.

On exact private staging and the production website, a Creator who has left the agency can be marked Deactivated by the agency Owner, or by an Admin with access to Creator accounts, and can be reactivated the same way unless its data has been deleted as described below. The Creator account and its linked Creator Profile share this one status, and a profile with no linked account carries it too; D1 records when the Creator was deactivated or reactivated and by which staff member, and each change is kept in the account audit records described below. Deactivation deletes nothing, except that the creator Discord bot clears the Creator’s own Discord user ID, as described for that bot below. While a Creator is deactivated, they cannot sign in to Creator Studio, their Team Member assignments are kept but give no access, and their calendar items are kept but hidden and not sent. Deactivated Creators are hidden from Admins, Team Leaders, and Team Members everywhere, except that an Admin with access to Creator accounts sees only the Creator’s name and username, that they are deactivated, and a control to reactivate them; the Owner continues to see everything.

On exact private staging and the production website, when a Creator Profile is linked to a Creator account, Aramingo creates that Creator’s content folder in the agency’s Google Drive, the same folder that Creator uploads use, if it does not already exist. Each profile has a switch, off by default, for sharing that folder with the Creator. If it is on, the Team Portal shows the Owner the folder link and the Creator’s sign-in email, and the Owner shares the folder with that email as view-only in Google Drive; Aramingo itself cannot share or unshare the folder. Google may send the Creator its own invitation or sharing email. Once the Owner confirms the folder is shared, a link to it appears in the Documents and Links section of the Creator’s account. D1 keeps the folder’s Google Drive ID, whether the switch is on, whether, when, and by which staff member the folder was last marked as shared or as no longer shared, and when the Owner was last reminded about it. When the Owner opens the list of Creators’ sign-in emails used for sharing, Aramingo records which page was opened and how many rows it showed, without any email or folder ID, and keeps that record for 90 days. When a Creator is unlinked, deactivated, or erased, or the switch is turned off, the Team Portal prompts the Owner to remove the Creator’s access in Google Drive, and on reactivation or relinking to restore it; the folder and its files stay in the agency’s Drive either way. If a profile’s record is cleaned up, or the profile is linked to a different Creator account, while its folder is still marked as shared, Aramingo keeps a small removal reminder, holding only the folder’s Google Drive ID, an internal record ID, and dates, and no name or email, until the Owner marks the access as removed. Whether a Creator still has access is based on the Owner’s own mark, not on a check of Google Drive.

The Owner also receives notices, shown in the Team Portal, sent by email, and, once the Owner switches on Discord alerts that involve people, posted to the Owner’s private Discord #creator-activity channel, when a Creator is deactivated or reactivated (with a reminder to share their Drive folder again if it was shared), when a deactivated, unlinked, or erased Creator’s folder is still marked as shared (at once and then daily until the Owner marks the access as removed), and when the Owner marks that access as removed. Each notice says what happened, with a date, and names the Creator by display name while one is still kept (a reminder about an erased Creator names no one); it never includes the Creator’s email address or any file.

On exact private staging and the production website, the Owner, or an Admin with access to Creator accounts, can also change a Creator’s sign-in email. A confirmation link is sent to the new address, and the change takes effect only when that link is opened within 24 hours; an address already used by another account is refused. When the change takes effect, all of the Creator’s sessions end, a linked Google sign-in is removed (passkeys stay), unused sign-in links, password-reset links, and challenges stop working, and a short notice that does not show the new address is sent to the old address. Each change is kept in the account audit records described below; the change request itself, including the old and new addresses, is deleted 7 days after it completes, is cancelled, or expires.

Documents & Links

Documents & Links shows Team accounts and Creators a list of links and documents the agency assigns to them, on exact private staging and on the production website. The Owner can assign links to the Owner, Admin, Team Leader, Team Member, or Creator audience or to an individual account of a lower role; an Admin, to the Team Leader, Team Member, or Creator audience or an individual in those roles; and a Team Leader, to the Team Member audience or an individual Team Member. Admins and Team Leaders need the Documents & Links area assigned to them. Team Members and Creators cannot add or change links, except that a Creator may change the address of a social media link assigned to them personally that staff marked as editable by them. Each account sees the active links for its own role or for itself; staff who manage an audience also see that audience’s removed links. A link is either a plain web address or a Google Drive document. Plain web addresses are never fetched or checked; they open in a new tab without sending the page address. For a Google Drive document, Aramingo asks Google Drive, using the agency’s Drive service account, for the file’s name, type, version, trashed state, and sharing settings when the link is added or changed and each time a list containing it is shown. Only the file ID and the service account’s credentials are sent to Google, never the link’s title or any staff or Creator identity. Aramingo does not read the file’s contents or change its sharing, and refuses a file shared with anyone or published to the web.

For each link, Aramingo’s D1 database keeps the audience (a role or an internal account ID), the title and optional description typed by staff, the kind, the web address (and, for a plain link, its host name), for a Drive document its file ID, file type, and Drive version number, the link category, whether the Creator may edit it, its status and position, a version number, the internal IDs of the staff member who created it and of whoever last changed it, and the created, updated, and removed times. Each change also keeps an operation record with a random key, the kind of change, the internal ID of the person who made it, the audience, a SHA-256 fingerprint of the request, and its result, so that a repeated request is not applied twice. The Drive file’s own name and sharing list are not stored. Active links have no expiry. Removing a link hides it at once and makes it eligible for permanent deletion 400 days later; operation records become eligible for deletion 90 days after they are made. Both cleanups run only when someone later changes a link and remove at most 50 rows at a time, so these periods are minimums, not exact deletion times. When a Creator or staff member leaves, their links stop being shown because only active accounts can see or be assigned links, but the link records, including the internal IDs of who created and last changed them, are not deleted automatically. Links are included in the nightly encrypted backups described below.

Creator tools

Creator Studio currently separates its browser-only transformation tools from the server-backed Influencer Name Generator and hybrid Caption Studio. The browser-only tools process selected files or text in page memory and temporary browser objects. Their input and output content is not written by the application to D1, R2, localStorage, sessionStorage, IndexedDB, Cache Storage, or analytics, except the saved presets, background images, saved watermark, saved credit, the editing-tool projects described next, and records that a tool’s own section below describes. Where a browser cannot ask where to save, or its save dialog fails, the Video Length Editor writes the shortened video to the browser’s private storage for this site so it can be downloaded; that copy stays only on the Creator’s device and is deleted the next time a video is saved or the tool is opened, or when the site’s browser data is cleared. Where a browser cannot ask where to save, Trailer Maker likewise writes the finished trailer to this site’s private browser storage so it can be downloaded; that copy is never uploaded, is not separated by account, and is deleted about two minutes after its download starts, when the Creator leaves the page, before the next trailer export, if an export fails or is cancelled, the next time Trailer Maker is opened, or when the site’s browser data is cleared. This no-persistence statement is limited to tool input and output content; ordinary authentication, security, rate-limit, and access records may still be processed.

In Creator Studio’s editing tools (such as Watermark, Trailer Maker, Video Studio, Thumbnail Maker, QR Code Maker, Caption Studio, Video Length Editor, and the image tools), a Creator’s own projects, up to 50 per tool, each with autosaved work, up to 20 earlier versions, and a small preview image made in the browser, are kept only in that browser’s storage on their device and are never sent to Aramingo. Each signed-in Creator’s projects are kept in a separate browser database whose name the website derives one-way from their account, without sending the account’s ID to the browser, so another Creator who signs in on the same browser does not see them, and staff tools never open them. Signing out does not delete them: they stay in that browser and appear again only when the same Creator signs back in. This separation is enforced by the website, not by encryption, so anyone with access to that browser’s stored data on the device could still read them. Pictures a project uses are copied into that browser storage: its main picture of up to 25 MB, Trailer Maker card backgrounds and Creative Effects photos of up to 25 MB each, and pictures added to a Thumbnail Maker design, which are first reduced to at most 4,096 pixels on each side and about 8 MB, with up to 100 MB of pictures per project. For videos, music, and larger files, the project keeps only their names, and for the main file its size and type and, where the browser allows it, a reference that lets the Creator reopen it from their device. A project also keeps the work itself, such as a QR Code Maker project’s link or text and a Caption Studio project’s caption text and timing. In Thumbnail Maker, a Creator can also save a design as one of My Templates, which is kept the same way, with its pictures and a preview, separately from their projects, until the Creator deletes it. Built-in templates are part of the website and contain no personal information. Applying the Creator’s My Brand kit to a design copies its colors, fonts, handles, and logo into that design on the device. Projects are not synced or backed up, and Aramingo sets no expiry for them. After a Creator first saves a project, the website asks the browser to keep this site’s stored data; the browser may ask the Creator first, and unless it agrees, it can still remove projects on its own, for example when storage runs low or, in Safari, after a while without use. Deactivating or deleting the Creator’s Aramingo account does not remove projects from the device. A Creator removes a project by deleting it in Recent, which also removes its earlier versions and copied pictures, or removes all of them by clearing this site’s browser data; when a tool already holds 50 projects, the Creator is asked to delete one before starting another. Using a different browser or device leaves projects behind, and a private browsing window may not allow them to be saved at all. The editing tools also remember in the browser that their first-visit tour was dismissed. Exports are files the Creator downloads, and a design is sent to the Creator’s Drive folder only if the Creator chooses Send to Creator Drive.

When Shared-Device Mode is available in Creator Studio, a Creator can turn it on for their account in a browser; it is off unless they choose it. While it is on, the editing tools save no new project content in that browser: no project settings, source files, pictures, previews, earlier versions or My Templates, and the website does not ask the browser to keep this site’s stored data. Work then stays only in the open tab until the Creator exports it or closes the tool. The browser keeps only an on/off setting for that account in localStorage, under a key containing the same account-derived one-way namespace, with no project content. Turning the mode on does not delete projects already saved. The Remove Saved Work control deletes from that browser only that Creator’s own saved projects, with their earlier versions, copied pictures and previews, their My Templates, and their Favorites and Recent lists; it does not touch other accounts’ work in the same browser or the downloaded AI model cache. The mode and the control do not encrypt anything, do not protect work from someone using that browser while the Creator is signed in or from browser extensions, do not remove files the Creator exported or downloaded, and do not securely erase the device’s storage. This disclosure does not switch Shared-Device Mode on.

When Favorites and Recent are enabled in Creator Studio, this browser can keep the IDs of tools you favorite and the last six tools you open, most recent first. It stores at most 100 favorite tool IDs and six recent tool IDs in localStorage, separately for each signed-in Creator account, under a key containing an account-derived one-way namespace rather than the raw account ID or email address. The saved lists contain no opening times, use counts, filenames, file contents or email addresses; these tool-choice lists are not sent to Aramingo’s server, synchronized between devices, or recorded in D1, R2 or analytics by this feature. Only tools the signed-in account is allowed to open appear in its shortcuts. The lists stay after sign-out and have no automatic expiry. Clear Recent clears that account’s recent list without removing favorites; unstar a tool to remove it from Favorites, or clear this site’s browser data to remove the stored lists. The “Forget my saved site settings” control below does not clear these separate tool-choice lists. If browser storage is blocked or unavailable, the feature cannot read or remember those choices; the tools remain subject to their ordinary access and capability requirements. This disclosure does not switch Favorites and Recent on.

Where available in Creator Studio, Background Removal, browser-local Video Captions, Speech Cleanup, Voiceovers, Image Upscaling, and Object Erasing, including on a picture selected in Thumbnail Maker, process your selected image, audio, text, or erase boxes on this device. These local processing actions do not upload your inputs or generated results or save them in the downloaded-model cache; in Thumbnail Maker, a result placed in a design is saved with that project on the device as described above. They still require access to the authenticated tool page and a compatible browser and device. Local captioning is used whenever this device supports it. If it does not, for example because the browser lacks support or memory, Caption Studio uses the conditional cloud service described below automatically for Creators, but only when that service is enabled for the account and unless the Creator has turned off “Use Cloud Captions When This Device Can’t”, which is on until they turn it off; with that setting off, captions are made only on the device. Cloud transcription can also be chosen directly under Advanced, subject to the same conditional service and restrictions.

Starting a browser-local AI feature may download pinned model files from huggingface.co and its allowlisted us.aws.cdn.hf.co distribution endpoint. Model requests omit browser credentials and the page referrer, but the download provider can still receive ordinary connection information such as your IP address and the requested model URL. Your selected media, entered text, erase boxes, and generated results are not included in those model-download requests. Provider handling and retention follow its own policies; Aramingo does not promise anonymous downloads or a particular provider-log deletion time. Read the Hugging Face Privacy Policy.

Verified model files may remain in the browser’s named aramingo-browser-local-ai-v1 cache so they can be reused. The model manifest limits admitted model files to 512 MB; this is not a guarantee about total browser storage or working memory. User inputs and generated results are not saved in that model cache. There is no fixed cache expiry: it may remain after leaving the tool or signing out, until you use Clear Downloaded AI Models for the current named cache or the browser clears or evicts it. Stop an active AI job before clearing that cache. Clearing it does not remove account cookies, other site preferences, your downloaded exports, or provider logs; using a model again may download it again. Cached models do not provide offline sign-in or bypass protected-page access.

The Influencer Name Generator is currently part of authenticated Creator Studio. When enabled, the influencer name generator is available only as an authenticated Creator Studio tool for active agency clients. It sends only the authenticated Creator’s bounded selected-energy value to Aramingo’s server and returns a generated name. The server keeps the name pool, blocked-name list, and selection rules. The generator does not retain the selected energy or generated name as a separate generator record. The Creator Studio name generator does not create a separate record of the selected energy or generated name. No separate generator record is written to D1, R2, browser persistence, or analytics.

Optional cloud transcription — only when enabled

Manual SRT/VTT import, editing, and export remain browser-local. Caption Studio also supports browser-local transcription where available. If you choose Transcribe with the Cloud under Advanced, or if this device cannot transcribe locally and “Use Cloud Captions When This Device Can’t” is on, and that service is enabled, it uses the conditional process below. It is used automatically only for Creators, and only when this device cannot transcribe locally, for example because the browser does not support it or does not have enough memory; before any audio is sent, Caption Studio shows how much will be sent and lets you cancel. Turning that setting off keeps transcription on the device only. Aramingo keeps the on/off setting with the Creator’s account.

The browser prepares only the audio the Creator chooses: either one creator-selected audio segment from a local audio or video file, or, if the Creator chooses the whole file, all of that file’s audio up to sixty minutes, split into no more than twelve equal parts. Each segment or part is prepared as normalized RIFF/WAVE PCM16 audio at 16 kHz mono and is limited to five minutes and under 10 MB. The full source file and filename are not sent.

Each normalized segment or part passes through Aramingo’s authenticated service to Cloudflare Workers AI as its own request, with the parts of a whole file sent about a minute apart, and the returned transcript is sent back to Caption Studio. Cloudflare states that Workers AI customer content is not used to train Workers AI models or improve Cloudflare or third-party services without explicit consent. Read the Cloudflare Workers AI data usage.

Aramingo’s automatic-transcription application does not write the submitted audio, returned transcript, filename, raw Creator identifier, provider payload, browser-supplied request data, or provider request/response content to application D1, R2, KV, queues, Durable Objects, browser persistence, analytics, or AI Gateway request/response logs. AI Gateway log collection is configured off. Page-state audio and results clear on cancellation, navigation, or reload.

A reusable D1 rate-limit row stores only a secret-keyed derivative of the Creator’s internal ID, a fixed internal discriminator, a request count, and the latest admitted time. It does not store the raw Creator ID, IP address, audio, transcript, filename, provider payload, headers, or request body.

A content-free and identity-free D1 budget ledger stores only the UTC budget date, reserved integer micro-USD, reservation count, and created and updated times. Best-effort cleanup targets a rolling 31-day UTC window and removes at most eight older aggregate rows per successful reservation; older rows may remain because of backlog, inactivity, or cleanup failure.

These application-storage limits do not mean the audio stays on your device or that providers process no metadata. Cloudflare and other service providers may process ordinary technical, security, and access information needed to deliver and protect the service.

Trailer Maker saved presets

The Trailer Maker editor works in the browser. Its account-save controls work only where separately reviewed server access is enabled, on exact private staging and, once the Owner switches Creator Studio on, the production website. If enabled, a signed-in Creator can deliberately save an intro, outro, or insert card design to their own account and later list, open, update, or delete it. Nothing is saved to the account unless the Creator chooses to save it. Each Creator can keep up to 25 saved presets across all card kinds; reusing a saved preset in a trailer does not use another slot.

For each saved preset, Aramingo’s D1 database would store the Creator’s internal account ID, an internal preset ID, the preset name (up to 120 characters), the card kind, and the card design: its background color, whether the background is a solid color or a private background image shown fit or stretched (with a reference to that image), an optional zoom-in or zoom-out motion, the card duration and fade length, and up to 12 text boxes of up to 160 characters each with their font, size, color, bold/italic/underline choice, position, rotation, selected social-platform logos, and whether the box is locked. It also stores a version number that increases with each change and the created and updated times. Updating a preset replaces its previous design; earlier versions are not kept as a history. Source video, audio, censoring, timeline projects, and exported videos are not part of a saved preset. Text is stored as typed, so do not put passwords or other sensitive information in card text or preset names. Only the Creator’s own account can list or change its presets. Saved presets are not sent to analytics or to outside services other than Cloudflare, which hosts the database.

Each save, update, or delete also creates a short-lived operation receipt so that an interrupted request can be retried without saving twice. A receipt keeps only internal Creator, operation, and preset IDs, the account’s lifecycle version, the operation type, the resulting version number, a SHA-256 fingerprint of the request, and its creation and expiry times; it contains no preset name, design, text, or image. Receipts expire after 24 hours, at most 256 are kept per Creator, and expired receipts are removed in batches of at most 25 during later saves. This is best-effort cleanup, not deletion at an exact time.

A saved preset may use a private still background image. If enabled, the Creator uploads a PNG image of at most 8 MB and 4096 pixels per side, and each Creator can keep up to 25 background images totaling at most 100 MB. Before storing it, Aramingo’s server checks that the file is a single non-animated PNG and removes embedded text, EXIF, time, and other non-image metadata, keeping only the image data and its color and transparency information. The image is stored in Aramingo’s private Cloudflare R2 storage, not at a public or shareable link, and is returned only to the signed-in Creator who owns it. D1 keeps the image’s internal ID, state, byte size, width and height, SHA-256 digest, version, and created, updated, and unused-since times.

Saved presets, and background images that a saved preset uses, are kept until the Creator deletes them; they have no automatic expiry. Deleting a preset removes it from Aramingo’s active application storage once the deletion succeeds and frees its slot; a failed deletion leaves the preset in place. A background image that a saved preset still uses cannot be deleted. When a Creator deletes an unused background image, it stops being viewable immediately and its file is then removed. A background image that no preset uses is removed 30 days after it was uploaded or last stopped being used, and using it again clears that clock; an upload that does not finish within 15 minutes is removed. These removals run in scheduled batches of at most 25, so they happen after, not exactly at, the stated time. Deletion does not immediately remove copies held in database backups or recovery copies. There is no self-service export or account deletion for saved presets or background images; a Creator may ask for a copy or deletion with Request My Data or Delete My Account on Profile Settings, or through the contact methods below.

My Brand kit

Where it is enabled, on exact private staging and the production website, a signed-in Creator can keep one My Brand kit with their account: up to 12 brand colors (each with an optional name of up to 40 characters), three font choices from the site’s own font list, up to 8 social handles (a platform and up to 64 characters of display text, never a link), a default logo, and their default watermark and credit, which are the same as the saved watermark and saved credit described below and stay in step with them. A Creator can also upload up to 10 logo images (PNG or WebP, up to 1 MB and 2,048 pixels on each side); Aramingo removes embedded metadata such as camera, location, and text details before storing them as private files in Cloudflare R2, with a database record of each file’s type, size, dimensions, and checksum. Only the Creator can see or change their kit, through their own signed-in session. The kit and logos are kept with the Creator’s account until the Creator deletes the kit or a logo, with no automatic expiry; a Creator may also ask for a copy or deletion with Request My Data or Delete My Account on Profile Settings, or through the contact methods below. They are included in the nightly encrypted backups described below, and restoring a backup does not bring back a logo or kit the Creator deleted.

Saved watermark

The Watermark tool works in the browser, and its “My watermark” save controls work on Aramingo’s exact private staging and on the production website. Where enabled, a signed-in Creator can deliberately save one watermark design to their own account and later load, replace, or remove it. Nothing is saved to the account unless the Creator presses Save.

For the saved watermark, Aramingo’s D1 database would store the Creator’s internal account ID and the design: the watermark text or handle (one line of up to 80 characters, which may be empty when a logo is chosen); up to six logos chosen from the tool’s built-in social-platform logos, and where they sit beside the text; the font, bold, italic, and underline choices, text case, text effect, style, color, opacity, and size; and the position (a corner, the center, or a chosen point on the picture) and rotation. It also stores a version number that increases with each change and the created and updated times. It never stores uploaded images, QR codes or links, file names, the picture or video the watermark was used on, or Leak-Trace recipients; adding the watermark to pictures and videos still happens in the browser. Text is stored as typed, so do not put passwords or other sensitive information in it. Only the Creator’s own account can load or change its saved watermark, and it is not sent to analytics or to outside services other than Cloudflare, which hosts the database. Marking a batch of copies with Leak-Trace creates only the Leak-Trace records described in the Leak-Trace section.

The saved watermark is kept until the Creator removes it or replaces it with a new save; it has no automatic expiry. A new save replaces the previous design, and earlier designs are not kept as a history. Removing it deletes it from Aramingo’s active application storage once the removal succeeds; a failed removal leaves it in place. Removal does not immediately remove copies held in database backups or recovery copies. There is no self-service export or account deletion for the saved watermark; a Creator may ask for a copy or deletion with Request My Data or Delete My Account on Profile Settings, or through the contact methods below.

Saved credit

The Metadata Stripper works in the browser, and its “My credit” save controls work on Aramingo’s exact private staging and on the production website. Where enabled, a signed-in Creator can deliberately save one credit to their own account and later load, replace, or remove it. Nothing is saved to the account unless the Creator presses Save, and the credit is written into a file only when the Creator chooses to apply it to that file.

For the saved credit, Aramingo’s D1 database stores the Creator’s internal account ID and the credit: a name or credit line (up to 120 characters), a copyright line (up to 160 characters), an optional website address (a secure https address of up to 200 characters), and a license chosen from a fixed list (all rights reserved; Creative Commons Attribution, Attribution-NonCommercial, or Attribution-NoDerivatives 4.0; CC0; or none). It also stores a version number that increases with each change and the created and updated times. Aramingo stores the website address only as text and never visits it. It never stores the files the credit is applied to, their names or locations, or anything read from them; removing metadata and writing the credit into a copy of a file still happen in the browser, and the files are not uploaded. Text is stored as typed, so do not put passwords or other sensitive information in it. Only the Creator’s own account can load or change its saved credit; team members cannot see it, and it is not sent to analytics or to outside services other than Cloudflare, which hosts the database.

The saved credit is kept until the Creator removes it or replaces it with a new save; it has no automatic expiry, and earlier versions are not kept as a history. While an account is disabled, its saved credit is kept but cannot be loaded or changed. Removing it deletes it from Aramingo’s active application storage once the removal succeeds; copies in Aramingo’s encrypted offsite backups are kept for at most 30 days, and restoring a backup never brings back a credit removed after that backup was taken. There is no self-service export or account deletion for the saved credit; a Creator may ask for a copy or deletion with Request My Data or Delete My Account on Profile Settings, or through the contact methods below.

Leak-Trace

Leak-Trace runs on Aramingo’s exact private staging and on the production website. If enabled, a signed-in Creator can make a separate copy of a picture or video for each person they send it to. Each copy carries an invisible mark unique to that recipient (in a video, in every frame and, when the video has sound, also as a very quiet mark in the sound), plus an optional small visible code or note the Creator chooses. If a copy is later shared without permission, the Creator can check it, or sound taken from it, to see which recipient’s copy it was. Pictures and videos are marked and checked in the Creator’s browser: the original, the marked copies, and any picture, video, or sound file being checked are never uploaded to or stored by Aramingo. Leak-Trace identifies whose copy was shared; it does not prevent sharing, and heavily edited, cropped, re-recorded, or sped-up or slowed-down copies may not be traceable.

To make a later check possible, Aramingo’s D1 database stores, for each original picture or video, the Creator’s internal account ID, an internal ID, the file name (up to 120 characters), a short visual fingerprint computed from the picture or from the middle frame of the video (a code used to recognize altered copies of the same original, from which the picture or frame cannot be rebuilt), and its width and height (for a video, the size of its marked copies); and, for each marked copy, a random mark ID, the recipient label the Creator types (up to 80 characters, for example a subscriber’s username), and the time the copy was made. The recipient label identifies a person, so a Creator should label copies only with what they need to recognize the recipient. For each check, D1 stores a report with the original’s internal ID, the result (match, inconclusive, or no mark), a confidence score, the matched mark ID only for a match, the visual fingerprint of the checked picture or of a frame of the checked video (a fixed placeholder when only a sound file is checked), whether the Creator or the agency team ran the check, and the time. Leak-Trace data is not sent to analytics or to outside services other than Cloudflare, which hosts the database.

The agency Owner and all Admins, and any Team Leaders the Owner individually gives Leak-Trace access, can choose a Creator to check a picture, video, or sound file against that Creator’s marked copies and to view that Creator’s originals, recipient labels, and check reports. Their checks are saved to the Creator’s reports as run by the agency team. Separately, staff can make a marked copy of a picture or video on a Creator’s behalf, mainly when they mark a custom request as sent to the fan: the agency Owner and all Admins for any active Creator, and Team Leaders and Team Members only for Creators whose Creator Information they can read as described in this policy. The marked file is made in the staff member’s browser and never stored, the copy counts toward the Creator’s limits, and the Creator does not see staff-made copies: if the Creator’s own check matches one, it says only that it is a copy made by the agency, without the recipient or staff member. Each staff-made copy also leaves a log record that only the agency Owner can see, with the staff member, the Creator, the original, the recipient label, any linked custom request, and the time; it cannot be changed, is kept for 400 days, and remains, including the recipient label, even if the copy’s record or the original is deleted or the Creator’s account is erased. Staff cannot see or delete a Creator’s originals, copy records, or reports through this, except that the person who just made a copy can remove that same copy’s record within 15 minutes if making the copy failed, and every request rechecks their access.

Each Creator can keep up to 1,000 originals, 500 marked copies for each original, and their 500 most recent check reports; when a new report would exceed that, the oldest reports are removed. Originals, marked-copy records, and reports otherwise have no automatic expiry and remain until the Creator deletes them. A Creator can delete a single copy’s record, an original together with all of its copy records, or a report; deletion removes it from Aramingo’s active application storage once it succeeds. A report kept after its original or copy record is deleted no longer shows the deleted name or recipient label. Deletion does not immediately remove copies held in database backups or recovery copies. Pictures, videos, and sound themselves are never stored, so there is nothing else to delete; copies already sent to recipients are outside Aramingo’s control.

Conditional Twitch Bot

The Twitch Bot (formerly the Twitch Clip Bot) runs only after separate activation, on Aramingo’s exact private staging or on the production website. On the production website it stays off until the agency Owner connects Aramingo’s production Twitch application by adding its credentials and switches the bot on, and clips there also wait for a separate video processing service that the Owner switches on separately. If enabled, a Creator, or the agency Owner for a named Creator, connects the Creator’s Twitch channel by signing in to Twitch and approving the channel:bot, clips:edit, and channel:manage:clips permissions. The Owner separately connects one agency-controlled Twitch bot account that listens for the clip command and posts replies.

For each connected Twitch account, Aramingo’s D1 database stores the Twitch user ID and login, the linked Creator’s internal ID (none for the bot account), the Twitch access and refresh tokens encrypted with AES-GCM under a versioned server key, the key version, a token generation number, the token expiry, the connection state, and created, updated, and last-validated times. Tokens are never sent to the browser. For the channel, D1 also stores the clip command, who may use it, cooldowns, the clip length, the chosen video formats and vertical layout, whether captions are on, the caption style, highlight color, and position, whether copies without captions are also saved, and the connection’s status and times. Each Twitch sign-in uses a one-time request that expires after 10 minutes; D1 keeps a keyed digest of it, the internal account that started it, the target Creator, and its outcome. Twitch’s one-time authorization code is held sealed and is removed when the attempt is used, or by scheduled cleanup after it expires; an expired code cannot be used. For each connected channel, D1 also keeps a record of Aramingo’s Twitch chat subscription: its Twitch subscription ID, status, callback address, application ID, version numbers, and any revocation reason, with no chat content.

While a channel is connected and the bot is active, Twitch sends Aramingo each chat message in that channel so the bot can recognize the clip command and, while a Creator’s overlay chat box is on, show the message in that overlay as described below. Aramingo checks the message for the command and the sender’s Twitch badges for permission; it does not store chat text, chatter names, or badges, except quotes and stream-marker descriptions that the broadcaster or a moderator deliberately saves and, when stream reports or chat filters are switched on, the chatter logins and IDs that the reports and moderation log keep, all described below. To avoid processing a message twice, it keeps a keyed digest of each Twitch message ID and a SHA-256 digest of the message body for at least 10 minutes, after which scheduled cleanup removes them in bounded batches. To enforce per-person cooldowns, it keeps a keyed digest of each chatter whose command started a clip, with the time, for at least one day, after which scheduled cleanup removes it in bounded batches. When a clip from a chat command finishes or fails, the bot may post one public reply in the channel’s chat: “Clip saved.”, “That clip could not be saved.”, or, when the Creator’s Twitch Clips folder is full, “That clip was not saved: the Twitch Clips folder is full.” It posts at most one reply per clip.

When a command is accepted, Aramingo asks Twitch to create a clip of the live stream, 5 to 60 seconds long as the Creator sets it (60 seconds unless changed), titled “Clip from chat”. Twitch creates and keeps that clip on the Creator’s Twitch channel under Twitch’s own controls, and Aramingo does not delete it from Twitch. If Twitch does not confirm the clip in time, Aramingo may make one attempt to clip the same span from the stream’s saved broadcast, and the first clip may still appear on Twitch. Aramingo downloads the clip, stores it privately in Cloudflare R2, and renders vertical and horizontal versions, according to the channel’s settings, in its Cloudflare Containers renderer. When captions are on, the renderer transcribes the clip’s speech with a speech-recognition model that runs inside that renderer, which has no internet access, and burns the captions into the video in the Creator’s chosen caption style, highlight color, and position; no transcript or caption text is stored or sent anywhere. If the Creator chooses captions “Both”, each chosen format is also saved a second time without captions. The finished videos are uploaded through Cloudflare to a “Twitch Clips” folder inside the Creator’s folder in the agency’s Google Drive, the same Drive described under Creator Shared Drive below. If the Creator has no folder there yet, the first clip creates it, with the same “unloaded” and “loaded” folders that a Creator upload creates; the clip bot’s earlier “Clips” folder is renamed “Twitch Clips” in place, keeping its files. Each file is named with the UTC date and time of the command (or of the trim or re-make request), its format, and whether it is trimmed, re-made, or without captions. Aramingo limits each Creator’s Twitch Clips folder, together with their own clip folders inside it, to 500 files in all, not counting files in the trash: it counts the files there before asking Twitch for a clip, and again before uploading. If the folder is already full, it does not create the Twitch clip; if the folder fills while a clip is being made, that clip is not uploaded (it stays on Twitch). Two clips finishing at the same moment can take the folder slightly past the limit. Files the Creator adds to the folder count toward it, and moving or deleting files in Drive makes room again.

A Creator can choose where new clips are saved: their Twitch Clips folder in Google Drive, which is the default, or one of their own clip folders inside it, which they pick from a list or create by name in the tool (up to 50, each name up to 60 characters). They can also add export notes of up to 500 characters for whoever edits their clips; each new clip’s file in Google Drive carries those notes as its description, where anyone who can open that file in Google Drive, including agency staff, can see and change them, and they are not used by any automatic processing. D1 keeps the chosen folder’s Google Drive ID and name and the notes with the Creator’s Twitch Bot settings, replaces them when the Creator changes them, and clears them when Twitch is disconnected or the Creator’s Creator Studio access is removed. Each clip job keeps a copy of the folder and notes it used until the job’s record is deleted, 30 days after the job finishes or fails. If the chosen folder no longer exists or Aramingo can no longer see it, the clip is saved to the Twitch Clips folder instead. Only the Creator can change these settings; on the team Twitch Bot page, the link to a finished clip’s Drive folder can lead to the chosen folder. A description saved with a clip in Google Drive stays with that file until it is removed through the agency’s Google Drive controls.

For six days after a clip from a chat command finishes or fails, the Creator can trim or re-make it from the Twitch Bot page. A trim chooses a new span of 5 to 60 seconds between two minutes before and 30 seconds after the original command; Aramingo then asks Twitch for one new clip of that span from the stream’s saved broadcast, also titled “Clip from chat” and kept on the Creator’s Twitch channel, and renders and saves it as above. A re-make, available once the clip’s source has been downloaded, renders that stored source again and creates no new Twitch clip. Trims and re-makes use the Creator’s current settings, are limited to two running at a time and 20 per rolling day, and post no chat reply.

The Twitch Bot’s chat features are off unless separately enabled on exact private staging or, once the Owner connects it, on the production website. If enabled, the Creator or their moderators can set custom command responses, counters (a name and a number), timed messages, and socials, lurk, welcome, and shoutout lines; D1 keeps these until they are edited or deleted, including after the channel is disconnected. The broadcaster or a moderator can deliberately save a quote from chat with !addquote or on the bot page. Aramingo stores the quote text (up to 300 characters), its number, whether it was saved from chat or the page, its original Date Added, and its edit version. On the bot page, authorized users may also manually enter or change an optional Said By label (up to 100 characters) and an optional Date Said (a calendar date, not a timestamp), or clear either field. Unknown attribution, including for older quotes, stays blank unless deliberately entered; Aramingo does not infer it from the chat sender, editor, Twitch identity, or save time. Editing a quote does not change its original Date Added. These quote fields remain until edited or the quote is deleted, including after the channel is disconnected. The quote record does not store who saved or edited it; separately described staff-action auditing still applies. While the welcome is on, Aramingo remembers which chatters it has seen so that it greets only a viewer’s first-ever message in the channel: for each chatter it keeps a keyed digest, with no Twitch ID, login, name, or message text, plus first-seen and last-seen times (last-seen is updated at most once a day) and, if the chatter was greeted, the stream and time. Chatters with a broadcaster, moderator, VIP, subscriber, or founder badge are never greeted or recorded. Before greeting someone, Aramingo asks Twitch once whether that chatter follows the channel, which needs the extra moderator:read:followers permission the Creator approves when turning the welcome on; a viewer who followed more than 30 days ago is not greeted, and the answer is used only at that moment and not stored. For its first 30 days it only records and greets no one. A chatter’s record is deleted after 365 days without chatting in the channel, including after the channel is disconnected; the first-time chatter’s own message is not stored. Otherwise it keeps only numbers and times: messages since the last timed message, bot messages sent, cooldown times, and the live stream’s ID and start time, refreshed at most once a minute. A chatter’s display name may be placed into a reply but is not saved. A shoutout also uses Twitch’s own Shoutout feature only if the Creator approves the extra moderator:manage:shoutouts permission. If the team Twitch Bot page is enabled, the agency Owner, and Admins or Team Leaders given Twitch Bot access, can see and change a connected channel’s chat features, commands, timers, counters, and saved quotes in the same way, including saving and deleting quotes, but cannot approve new Twitch permissions for the Creator.

A command can also have up to 100 alternative replies plus a default, which the Creator, or team members given Twitch Bot access with each change recorded in the account audit log, can add, edit, and delete. They choose how the bot picks a reply (at random, weighted, in order, or shuffled) and can add conditions: the time, day, or date; how long the stream has been live; the viewer count; the game or words in the stream title; how fast chat is moving; the chatter’s role; whether it is the chatter’s first message; how long the chatter has followed the channel; how many times the chatter has used the command; a counter’s value; uses this stream; a random chance; or a recent raid, Hype Train, or sponsor message. D1 keeps the replies, conditions, pick setting, and each reply’s cooldown and last-use time until the Creator deletes them or the command. Chat speed is measured only as a count of messages per minute, and chat messages are not stored. The first-message condition uses the first-time-welcome records described above and works only while that welcome is on. The follow-length condition asks Twitch at that moment, with the moderator:read:followers permission, and nothing about the follow is stored; without that permission the condition never matches. To check use-count conditions, Aramingo keeps, for each command and chatter, a keyed digest made from the channel and the chatter’s Twitch user ID (never the ID or a name), a count, and the time of last use; each channel keeps at most 50,000, dropping the least recently used first, and each is deleted 365 days after its last use. It also keeps a count of each command’s uses in the current stream, with no chatter, deleted when the stream ends or 48 hours after its last use. A backup restore does not bring back use counts.

The Creator can also set up to 50 automatic rules, each off until the Creator turns it on. A rule runs by itself on a schedule or at a point in the stream, when a stream starts or ends, on a raid, follow, subscription, resubscription, gifted subscription, cheer, or Hype Train, when a poll or prediction ends, when a counter reaches a value, when a clip or marker is made, when chat has been quiet, on a stream’s first chatter, at a viewer milestone, or on a burst of emotes; it then posts a message, replies as one of the Creator’s commands, or adds a stream marker. Only the Creator can create or change rules. Subscription, cheer, and Hype Train rules need extra Twitch permissions (channel:read:subscriptions, bits:read, and channel:read:hype_train), each requested only when a rule that needs it is turned on. Follow rules use the moderator:read:followers permission described above, requested the same way if the Creator has not already approved it. When a rule thanks someone, their display name and, where relevant, the amount (such as months, gifts, or bits) are placed into that one chat message and not kept. D1 keeps each rule (its name, trigger, action, any message or marker text the Creator types, its cooldown, and when and in which stream it last fired) until the Creator deletes it; a record that a rule fired for a particular stream, day, or event, deleted after 7 days or with the rule; and, for each channel, only times and counts: when chat last had a message, which stream’s first chatter was greeted, the last raid and Hype Train times, the highest viewer milestone this stream, and the number of emotes in chat per 5 seconds, kept for 2 minutes. No chatter ID, name, or message text is stored for these rules.

The Twitch Bot’s stream tools are also off unless separately enabled on exact private staging or, once the Owner connects it, on the production website, and the Creator switches each one on. Stream markers, polls, and predictions each need an extra Twitch permission that the Creator approves only when turning that feature on (channel:manage:broadcast, channel:manage:polls, or channel:manage:predictions). The Creator can type sponsor names and messages for the bot to post; D1 keeps them until they are edited or deleted, and a deleted sponsor’s name stays in past stream reports. After each stream, Aramingo keeps a stream report with only totals (chat messages, distinct chatters, commands, clips, quotes, markers, polls, predictions, new follows, and sponsor messages shown), the stream’s start and end times, and the Twitch logins of the five chatters who sent the most messages, with their message counts. New follows are counted only if the Creator already approved the moderator:read:followers permission for the welcome; otherwise the report says “Not tracked”. A new follow only adds one to a count; follower identities are not stored. To find the top five chatters, Aramingo keeps a temporary tally during the stream of a keyed digest of each chatter, their current login, and a count; the tally is deleted when the stream ends, and a scheduled cleanup removes any left after 48 hours. Reports, including the top-chatter logins, cannot be deleted early and are removed by a scheduled cleanup 365 days after the stream ends. When the Creator or a moderator adds a stream marker, Aramingo keeps a copy of the stream, the position, and any description they type (up to 140 characters), for 365 days and at most 2,000 per channel; deleting Aramingo’s copy does not remove the marker from Twitch. For polls and predictions it keeps the title, choices, duration, status, and totals for each choice, never individual votes or predictions; each channel keeps the last 100, and each is removed by a scheduled cleanup after at most 365 days. These scheduled cleanups run in batches, so shortly after rather than exactly at the stated time, and continue even if the features are switched off or the channel is disconnected. The !schedule command posts only the title and time of events the Creator adds with “Schedule a Stream”, never event descriptions. If the Creator pastes their own Discord webhook address for going-live alerts, Aramingo stores it encrypted and never shows it again, including to the agency, and keeps it until the Creator removes or replaces it. When the stream starts, the alert posts the Creator’s own message once, which can include their Twitch login, stream title, and category from Twitch, only to the Creator’s own Discord channel, with pings turned off unless the Creator chooses one role in their own Discord server for the alert to mention, in which case it mentions only that role. Aramingo keeps only that role’s Discord ID (never its name), which is cleared whenever the Creator replaces the webhook address and deleted when the webhook is removed, the Twitch stream it last alerted for (so it alerts once per stream), and the latest alert’s result and time. The agency Owner, and Admins or Team Leaders given Twitch Bot access, can see every connected channel’s stream reports, polls and predictions, and whether an alert is set up and its latest result, and can add, edit, and delete sponsors; they never see the webhook address or the role it mentions and cannot set, test, or remove the webhook or choose its role, start markers, polls, or predictions, or delete marker copies. The stream tools never store chat message text.

The Twitch Bot’s chat filters are off unless separately enabled on exact private staging or, once the Owner connects it, on the production website, and switched on by the Creator. The Creator chooses which filters to use (personal contact details, banned words, links, spam, and all-caps) and can type a banned-word list and allowed link domains, and set the strike count, strike window, and raid-shield timings; D1 keeps these settings until they are changed, including after the channel is disconnected. When a switched-on filter matches, the bot deletes the message; once the same chatter reaches the Creator’s strike count within the strike window (3 matches within 10 minutes unless the Creator sets 2 to 10 matches within 1 to 60 minutes), it also times that chatter out, for 60 seconds unless the Creator sets another length between 10 and 600 seconds or switches timeouts off. A match for personal contact details is only deleted and never leads to a timeout. The bot never bans anyone. Messages from the broadcaster and moderators are never filtered; VIPs are not filtered unless the Creator chooses, and subscribers are filtered unless the Creator exempts them. Deleting and timing out need the extra moderator:manage:chat_messages and moderator:manage:banned_users permissions, which the Creator approves separately. If the Creator turns on the optional warning, the bot posts a short sentence in chat naming the chatter and the filter. The Creator may reword the removal and timeout sentences (up to 200 characters each), using only the chatter’s display name, a fixed description of the filter, and the timeout length; the sentence never includes what the chatter wrote or the matched word, and the Creator’s wording is kept with the chat-filter settings until changed. Each action is recorded in a moderation log that stores the chatter’s Twitch login and user ID, which filter matched, what the bot did and whether Twitch accepted it, and the time; it never stores the message text. Log entries are deleted after 90 days by a scheduled cleanup that runs in batches, so shortly after rather than exactly at 90 days, and continues even if the filters are switched off or the channel is disconnected; each channel keeps at most 2,000 entries, with the oldest removed first when a new one is added. The Creator, the agency Owner, and team members given Twitch Bot access can see the log; only the Creator can delete one entry or all of them. To count repeat matches, Aramingo keeps a keyed digest of the chatter, with no Twitch ID or name, plus a count and the start of the strike window, and deletes it about 10 minutes after the window ends. Team members given Twitch Bot access can also change the filter settings. Before any change a team member makes to a Creator’s Twitch Bot is saved, Aramingo’s account audit log records which team member, which Creator, what kind of change, and when; if that record cannot be written, the change is refused. These records follow the retention for other account and Creator audit records described below.

The raid shield is part of the chat filters. It is off unless separately enabled on exact private staging or, once the Owner connects it, on the production website, and switched on by the Creator, and switching it on needs the extra moderator:manage:chat_settings permission; Twitch’s Shield Mode is used only if the Creator also chooses it and approves the moderator:manage:shield_mode permission. While the raid shield is on, Twitch tells Aramingo when another channel raids the Creator’s channel. For the raid shield, Aramingo uses only the raid’s viewer count, at that moment, and does not keep the raiding channel’s ID, login, or name. When a raid meets the Creator’s minimum size (50 viewers unless the Creator sets a number between 2 and 100,000), the bot turns on followers-only chat (for accounts that have followed for at least 10 minutes, unless the Creator sets 0 to 60) and slow mode (30 seconds, unless the Creator sets 3 to 120), plus Shield Mode if chosen, and turns them off again after the shield time (10 minutes unless the Creator sets 1 to 60), within about 5 minutes after it ends; another raid during that time extends it. It turns on only settings that were off, and never turns off a setting it did not turn on or that a moderator has since changed. While a shield is on, D1 keeps the channel’s earlier followers-only, slow-mode, and Shield Mode settings, exactly what the bot changed, and when; that record is deleted once the settings are restored. If the restore still cannot run a day after it was due, a scheduled cleanup deletes the record shortly after that; this cleanup runs only while the Twitch Bot itself is running on Aramingo’s service (even with the chat features switched off), so a record can remain until the bot is running again. The Creator’s raid-shield settings (on or off, the minimum raid size, and the Shield Mode choice) are kept with the other chat-filter settings. Team members given Twitch Bot access can change them, and each change is recorded in the account audit log, but they cannot approve Twitch permissions.

Streamer.bot is free software that a Creator may choose to install on their own computer; Aramingo does not install, provide, or control it. The Twitch Bot’s Streamer.bot connection is off unless separately enabled on exact private staging or, once the Owner connects it, on the production website. A Creator turns it on by making a connection key on the Twitch Bot page and pasting it into Streamer.bot. The key is shown to the Creator once; Aramingo stores only a keyed digest of it (never the key itself), which actions it allows, and when it was created and last used (updated at most once a minute). Making a new key replaces the old one at once, and turning the key off deletes it. With the key, Streamer.bot can ask Aramingo to make a clip, add a stream marker, add a marker for a big raid, a Hype Train, or a burst of channel-point redemptions, report the current OBS scene, start or end a sponsor’s time on screen, start or end a break, report that the stream started or ended, run the panic button, start or end one of the Creator’s saved polls, raid the next live channel on the Owner’s raid-train list, or upload a replay, as described below. Apart from a replay’s video, its requests carry only the action and its details, such as the OBS scene name, a marker note, a raid’s viewer count, a Hype Train level, or a channel-point redemption’s ID, never chat text or viewer names. Clips, markers, and the end-of-stream report are made the same way as from the Twitch Bot’s chat command or page, with the same permissions, cooldowns, and records described above; a sponsor scene logs that sponsor’s time on screen, and pause scenes and breaks hold the Creator’s sponsor messages. Only the Creator can see or change the key and the Streamer.bot settings; team members cannot.

The panic button runs only the steps the Creator has chosen: clearing all messages from the channel’s chat with Twitch’s clear-chat feature, using the moderation permission the Creator already approved (the cleared messages are not stored), and turning on the raid shield described above without waiting for a raid, with the Creator’s own raid-shield timings, if the Creator has switched the raid shield on and approved its permission. Local steps, such as switching to a safe scene or muting a microphone, happen inside Streamer.bot on the Creator’s computer and are not sent to Aramingo. A third choice, alerting the agency, is not yet active and sends nothing. Each press is recorded with its time and a short result code for each step (such as done or failed), never chat text, and kept for 90 days.

For the Streamer.bot connection, D1 also keeps the Creator’s settings until the Creator changes them: up to 10 OBS scene names, each tied to one of the Creator’s sponsors; up to 10 scene names that pause sponsor messages; the raid, Hype Train, and redemption-burst thresholds for markers; up to 6 named break lengths; and the panic-button choices. It keeps the current state, which each request overwrites: the current OBS scene name, whether a sponsor is on screen and since when, any running break, a count of recent channel-point redemptions, when each kind of hype marker was last added, and when Streamer.bot last called. It keeps a log of when each sponsor was on screen, with the stream and the start and end times, deleted 365 days after it started. To ignore a repeated request, it keeps a digest of each request for 5 seconds (30 seconds for the panic button). Scheduled cleanups delete these in batches, so shortly after rather than exactly at the stated time, and run with the Twitch Bot’s scheduled work even if Streamer.bot is switched off. To limit abuse, Aramingo counts requests per key and per network address in its rate-limit records, which store only keyed digests, never the key or the address, for the same 15-minute windows as the sign-in limits. A backup restore does not bring back a key that was replaced or turned off.

On the same page, the Creator can save a vertical clip layout for up to 20 OBS scenes: the scene name and the position of one or two areas of the picture, stored only as numbers, until the Creator changes or deletes it. To draw a layout, the Creator can open a screenshot in the browser; it is never uploaded or stored. When Streamer.bot asks for a clip, it can send the current scene name; the clip job then records that scene name and, if the scene has a layout, a copy of it at that moment, and the clip’s vertical version is framed with it. Trims and re-makes of that clip use the scene’s current layout. Clips from the chat command record neither.

Where separately enabled on exact private staging or, once the Owner connects it, on the production website, Streamer.bot can also upload a replay that OBS saved on the Creator’s computer, up to about 1 GB and 180 seconds long, with at most 10 uploads started per day and 2 in progress at a time. The video is sent in parts to Aramingo’s private Cloudflare R2 storage. Aramingo checks its size and SHA-256 digest against what Streamer.bot declared and deletes it if they differ; otherwise it renders the replay and saves it to the Creator’s Twitch Clips folder in Google Drive, as described above for clips. A replay never asks Twitch to make a clip and never sends the clip command’s chat reply; like any new clip, it can run the Creator’s own “clip saved” automatic command described above. For each upload, D1 keeps the declared size, length, and digest, the upload’s progress, state, and expiry, and deletes these upload records 7 days after the upload finishes or ends; an upload that is never finished expires, and its parts are deleted. The replay’s clip job is kept like other clip jobs and also records how many seconds rendering took and how much it stored, which the Clip Bot page uses to estimate its cost; the private R2 copy follows the same deletion schedule as other clip videos.

The Creator can save up to 25 poll presets (a name, a title, 2 to 5 choices, and a duration), which D1 keeps until the Creator changes or deletes them. Streamer.bot can start a saved poll by its name, or end the running poll, through the Twitch Bot’s polls feature and its permission; it cannot start a poll from free text. For the agency Owner’s raid train, the Owner keeps an ordered list of Creators in D1, which only the Owner can change. Only a Creator on that list can allow raids on their Streamer.bot key and approve the extra Twitch permission it needs (channel:manage:raids). When Streamer.bot asks to raid, Aramingo asks Twitch which channels on the list are live, without storing the answer, and starts one raid to the next live channel after the Creator’s own, never to a channel named in the request. It keeps only the time of that Creator’s last raid attempt, so a Creator can try at most once every 10 minutes, whether or not Twitch started the raid, and it never retries a raid. Only the Creator can see or change their poll presets.

Where separately enabled on exact private staging or, once the Owner connects it, on the production website, and while the bot’s chat features are on, the Creator can also set milestones for followers, subscribers, and bits (an “every N” step and up to 20 exact totals for each), with one shared set of switches for what happens when any milestone is reached: a chat line from one template (up to 300 characters), a clip, and a post to the Creator’s own Discord going-live webhook. D1 keeps these settings until the Creator changes them. When Twitch reports a new follow, subscription, or cheer, Aramingo reads the channel’s follower or subscriber total from Twitch (at most once a minute), or adds the cheer to a running bits total that restarts whenever the settings are saved, and keeps only the latest total. Each milestone fires once, and D1 records which milestone fired and when; after the settings are saved, bits milestones can fire again. The Discord post names only the channel and the number. Twitch’s notices, and its replies that carry a total, can name a follower, subscriber, or cheerer; Aramingo uses only the numbers and never stores or shows who it was. Aramingo receives follow, subscription, and cheer notices from Twitch only while a milestone with a switched-on action is set and the Creator has approved that permission (moderator:read:followers, channel:read:subscriptions, or bits:read). Only the Creator can see or change their milestones.

The Twitch Bot’s OBS overlays are off unless separately enabled on exact private staging or, once the Owner connects it, on the production website. A Creator can switch on overlay widgets (an alert box; follower, subscriber, and bits goals; an event list and latest event; a chat box; a clip-saved pop-up; and a sponsor banner) and add each one to OBS, the Creator’s own streaming software, with its own secret link. While an overlay is open, Aramingo passes it follows, subscriptions, gifted subscriptions, cheers, and raids (the viewer’s Twitch display name and, where relevant, the tier, months, count, or amount), notices that a clip was saved or a sponsor is on screen, and, for a chat box, chat messages (the chatter’s display name and the message text, up to 500 characters, with emote images that OBS loads from Twitch). These are shown and then dropped: Aramingo does not store them, and reloading an overlay starts it empty. A chat box shows only messages that the bot’s chat filters have not removed, and a message a moderator deletes, or a chat clear, also disappears from the overlay. Alerts and goals for follows, subscriptions and gifts, and cheers need the Twitch permissions the Creator approves for them (moderator:read:followers, channel:read:subscriptions, and bits:read), and Aramingo subscribes to Twitch’s chat-deletion and chat-clear notices only while a chat box is on. For goals, Aramingo reads only the channel’s follower total and its subscriber total and points from Twitch, at most every 5 minutes and only while a matching goal is on; bits are counted from when the goal starts. Only the Creator can see or change overlay settings and links; team members cannot.

D1 keeps each widget’s switch and style (colors, font, layout, position, animation, duration, text templates, and any goal’s title, target, and dates) until the Creator changes them. For each widget’s link, D1 stores only a keyed digest, never the link itself, with when it was made and when OBS last used it (updated at most every 10 minutes); the full link is shown to the Creator only when it is made. The Creator can replace a link or turn it off, which closes any overlay using it; a replaced or turned-off link’s record is deleted about 30 days later by a scheduled cleanup that runs in batches, even if overlays are switched off. Separately from D1, and outside Aramingo’s backups, each channel’s overlay service keeps only the Creator’s internal ID, the current goal numbers and when Twitch’s totals were last read, the name of the Creator’s sponsor while it is on screen, and a count of how many times the service started that day; while an overlay is connected, it also holds which widget it shows, a keyed digest of its link, and when it connected and was last checked, and drops these when the overlay disconnects. Overlay pages set no cookies, are not indexed by search engines, and are not stored by browsers. The link’s secret is kept in the part of the address that browsers do not include in requests or pass on to other sites; the overlay page sends it to Aramingo only in a request header, and Aramingo stores only a keyed digest of it. Aramingo’s rate limits count overlay requests only by keyed digests of the link and the network address, for 15-minute windows.

The Twitch Bot’s growth stats are off unless separately enabled on exact private staging or, once the Owner connects it, on the production website, and switched on by the Creator. While they are on, Aramingo reads the channel’s follower total from Twitch once a day, using the Creator’s existing Twitch connection and no new permission, and, while the channel is live, Twitch’s viewer count about every 5 minutes. D1 keeps, for each day, the follower total and when it was read, and, for each stream, Twitch’s ID for the stream, its start and end times (the end time is estimated if no viewer count arrives for 24 hours), when the last viewer count arrived, the highest viewer count, the number and sum of the viewer counts (to work out the average), and the follower totals at its start and end. These are totals only: no viewer’s, follower’s, or chatter’s Twitch ID, login, or name is read or kept. Daily totals are deleted 400 days after their day, and stream records 400 days after the stream ends, by a scheduled cleanup that runs in batches, so shortly after rather than exactly at that time, and continues even if growth stats are switched off. The Creator can see them on the bot page, and the agency Owner, and Admins or Team Leaders given Twitch Bot access, can see them read-only; only the Creator can switch growth stats on or off. Downloading them as a spreadsheet or printing them happens in the browser.

The creator Discord bot, a separate Discord application called “Aramingo Community”, is off unless separately enabled on exact private staging. A Creator can add it to one Discord server of their choice. Adding it asks Discord only for the bot, slash-command, and identify permissions and the abilities to view channels, send messages, manage roles, and manage events, never administrator rights. The identify permission is used once, to read the Creator’s own Discord user ID; Aramingo then asks Discord to revoke that sign-in, never stores it, and keeps nothing else from it. The bot does not read messages, the member list, or who is online. In the Creator’s server, anyone can use /schedule, /socials, /quote, and /command, which follow the Creator’s Twitch Bot switches and post publicly, in the channel where they are used, the same upcoming stream titles and start times, social links, saved quotes, and custom-command replies (only those open to everyone) that the Twitch Bot uses; like a use in Twitch chat, /command also updates when that command was last used. Discord sends Aramingo the member’s account details with each command, and Aramingo neither stores nor uses them. Each command answers publicly at most once every 5 seconds per server. Two private forms, /report-leak and /business, only answer that they are not available yet, and store nothing. If the Creator switches on the bot’s other features, it also posts each clip made with the chat command in the last day, as a Twitch link, to a channel the Creator picks; posts the Creator’s own announcement once when a stream starts, which can include the channel, stream title, and stream link; gives the Creator’s own Discord account a role the Creator picks while the stream is live and takes it back afterward; and copies the Creator’s timed “Schedule a Stream” events for the next 14 days into that server as Discord events, with only the title, the start and end times, and the location “Twitch”, updating or deleting them when the calendar changes. Its replies and posts never mention or notify anyone. Only the Creator can see or change these settings; team members cannot.

For the creator Discord bot, D1 keeps the server’s Discord ID and when it was added, the Creator’s own Discord user ID (for the live role), the channels and role the Creator picked, the on/off switches, and the announcement text. When the Creator disconnects the bot on the Discord Bot page, the Creator’s Discord user ID is cleared at once, and the rest is kept for 30 days, so that adding the bot back to the same server restores the settings, then deleted. If the bot is removed from the server in Discord instead, Aramingo notices within about an hour while the bot is switched on, and handles it the same way; while the bot is switched off, a removal is noticed only once it is switched back on. If the Creator’s account is deactivated, the bot stops posting, changing the role, and copying events in that server, its commands answer that it is not connected, and the Creator’s Discord user ID is cleared within a few minutes; reactivating the account does not restore it, so to get the live role back the Creator disconnects the bot on the Discord Bot page and adds it again (the server’s settings are restored). For each copied event, D1 keeps the calendar event ID, the Discord event ID, the server, a digest of what was sent, and the event’s end time, deleted 30 days after the event ends or when the event is removed. To post each clip, announcement, and role change only once, and to apply the 5-second limit, it keeps keyed digests of the server and, where relevant, the command, clip, or stream, never a member’s ID, for 5 seconds to 30 days. A request to add the bot keeps a keyed digest of its one-time request token (Discord’s own sign-in code is never stored), usable once within 10 minutes and deleted an hour after it expires. Scheduled cleanups delete these records in batches, so shortly after rather than exactly at the stated time, even if the bot is switched off. Restoring a backup never brings back these short-term digests or makes the bot create the same Discord event twice. Discord keeps the bot’s posts, the role, and the events in the Creator’s server under its own policy.

Each clip job in D1 records an internal job ID, the Creator’s internal ID, whether it came from a chat command, a trim, a re-make, or a Streamer.bot replay upload, the original job it came from, any trim start and end, the Twitch clip ID, the clip length and render and caption settings used, for a clip requested from Streamer.bot the OBS scene name and, if that scene has one, a copy of its vertical layout, the job’s state and any failure category, the sizes and SHA-256 digests of the source and rendered videos (including any copies without captions), whether each upload finished, the Twitch Clips folder link, whether the chat reply was sent, and lifecycle times. It does not store chat text, the chatter’s identity, Twitch’s temporary download link, or tokens. The Creator’s Twitch Bot page shows each recent job’s ID, time, and state, with the Drive folder link once the job is complete. If the team Twitch Bot page is enabled, the agency Owner, and Admins or Team Leaders given Twitch Bot access, can see each connected channel’s Twitch login, the Creator’s name, recent clip job status and failure reasons, and links to the Twitch Clips folder and the public Twitch clip, and can retry a failed job without creating a new clip; a retried job also records its retry count and latest retry time.

The private R2 copies of the source and rendered videos are deleted seven days after a job finishes or fails, by a scheduled cleanup that runs whether or not the clip feature is switched on. A clip job’s record is deleted 30 days after the job finishes or fails, once its private R2 videos have been deleted, but is kept while a trim or re-make made from it, or a replay upload record that names it, is still kept. Channel settings, connection records, and Twitch event subscription records have no automatic deletion schedule. Records of each Twitch sign-in attempt (its keyed digest, the internal account that started it, the target Creator, its outcome, and its times) also have no automatic deletion schedule; the sealed authorization code is removed when the attempt is used, or by scheduled cleanup after it expires. Videos uploaded to Google Drive remain until they are removed through the agency’s Google Drive controls, and clips on Twitch remain under the Creator’s and Twitch’s control. Disconnecting Twitch immediately stops the bot for that channel and deletes the stored tokens. Aramingo then asks Twitch once to revoke the access token, but cannot guarantee that Twitch confirms it, so a Creator can also remove the connection in their Twitch account settings. The connection record without tokens, the channel settings, chat-feature and chat-filter settings, saved quotes, sponsors, and the encrypted Discord webhook address are kept after disconnection; past job records, moderation log entries, stream reports, marker copies, and poll and prediction records are kept until their scheduled deletion.

Cloud captions and Twitch replay clips have monthly usage limits. The agency Owner can switch either feature on or off for the whole site, set one monthly spending cap for both, and set or raise a monthly limit for an individual account; the Owner’s own account has no individual limit. Each time someone uses cloud captions or makes a replay clip, D1 records their internal account reference, the feature, the calendar month (UTC), the amount used (seconds of audio for captions, or one clip or replay) and its estimated provider cost, with times. These records hold no media, filename, or transcript. A Creator can see their own use and what is left for the month, and only the Owner can see each account’s use and limits. A use record is deleted 400 days after it is created, once that use has finished. Each change the Owner makes to the switches, the cap, or an account’s limit is kept in a change log with the Owner’s and that account’s internal references, and is deleted after 400 days.

Twitch processes connected accounts, chat, and clips under its own policy. Read the Twitch Privacy Notice.

Discord receives the Owner’s alerts in the Owner’s private server and, for a Creator who adds their own webhook, that Creator’s going-live alerts, and processes them under its own policy. Read the Discord Privacy Policy.

Creator Shared Drive — only where configured

Creator Shared Drive upload is offered in Creator Studio through the Creator Drive page and, where it is configured, a “Send to Creator Drive” option after a tool saves a file. Its server control plane also fails closed unless exact runtime gates and provider credentials are valid. If it is enabled and a Creator chooses a file, the upload travels directly from the authenticated browser to Google Drive. To verify a new upload, the Cloudflare Worker reads Google’s file metadata and at most the first 65,536 bytes (64 KB) of the file from Google Drive, which can be the whole file if it is smaller. It compares the selected file’s checksum with Google’s reported checksum and checks that short portion for a supported file format. The verification code holds the portion in temporary memory and clears its working buffer after the check; it does not save a file copy. These checks are not a malware scan, complete file decoding or validation, or a guarantee that the file will never change. Cloudflare also handles bounded reservation and completion metadata such as Creator and opaque submission identifiers, filename, MIME type, byte length, expected file checksum, state, quota day, and lifecycle times. Google Drive stores the file. Where enabled on exact private staging and the production website, the agency Owner or an Admin can also send a file saved in a Team Creator Tool to an active Creator’s agency Drive folder. The upload and verification follow the same process; the upload is recorded against that Creator and counts toward that Creator’s daily limit, the Creator is notified that a file arrived, and an account audit record keeps which staff member sent it, to which Creator, and when.

For each new upload, D1 stores the selected file’s expected SHA-256 checksum with its Creator-linked upload reservation. This content fingerprint is used to compare the file with Google’s reported checksum; it can be linked to the Creator and is not anonymous. The freshly observed Google file ID, version and checksum are used for verification, not added as separate stored fields. Verification-prefix bytes are not saved to these Shared Drive records. After receipt is verified, D1 may also keep a Creator-linked event kind, the canonical allowlisted Google Drive folder URL as the sole stored Drive locator, internal event and deduplication identifiers, occurred and created times, per-Creator observation state and times, internal reconciliation lease, cursor, count, version, and update state, and event-to-staff read state containing the internal event identifier, a bounded internal staff-principal identifier, and the read time. These Shared Drive records do not store a raw Google or other provider identity, a separate raw Drive folder ID, provider token, upload capability, provider response payload, or file bytes.

The expected checksum stays with its upload row and has no separate retention extension. A pending reservation becomes unusable after seven days but may remain physically pending until guarded reconciliation marks it terminal. On qualifying mutations, best-effort cleanup targets terminal upload rows updated more than 90 days ago and event rows created more than 365 days ago, deleting at most 25 of each for that Creator. Staff event-read rows are deleted only when their event is pruned. These targets are not fixed deletion schedules and do not apply to observation or reconciliation state. None of these limits deletes the Google Drive file. The current provider contract has no automatic provider-file deletion guarantee; Drive content remains until it is removed through the agency’s Google Drive controls. D1 upload records, including retained checksums, are included in the separate encrypted backups described below; removing an application record does not immediately erase an existing backup copy.

Conditional Agency Team Calendar

The Agency Team Calendar is disabled unless separately configured and enabled. If enabled, an authenticated Creator uses Creator Studio to create, view, edit, or delete their own events, and authorized Team staff may manage their own staff events. Creator and staff event titles, details, and times are sent to and stored in the same agency-owned private Google Calendar. Google Calendar also stores a server-derived internal Creator ID or staff-principal ID in private event metadata to bind each event to its owner; for these general events, Aramingo does not create a separate D1 calendar or synchronization table. The separate planned-shift records and synchronization described above do use D1. Agency employees with the configured Google Calendar reader access can see event details. Creators are not given direct Google Calendar access or added as event attendees, and the application does not send event invitations. General Creator events remain until the Creator deletes them or an authorized agency operator removes them; general staff events remain until their staff owner deletes them or an authorized agency operator removes them. Neither kind of general event has timed retention or automatic cleanup. On exact private staging and the production website, an eligible ordinary Admin or Team Leader individually assigned the Owner Calendar may read a bounded agency-wide view of Creator and staff account labels, event titles and descriptions, start and end times, and all-day state. This delegated view does not include checklist tasks or notification history. The read-only view rechecks the actual recipient session, role, assignment, and version before releasing data and closes future reads after revocation; information already seen cannot be erased. Assignment does not enable the calendar or grant event creation, editing, deletion, global notification preferences, connected Google Calendar access, or provider writes. This disclosure does not enable the feature.

While the Agency Team Calendar is enabled, Aramingo also creates notices when calendar events are added, start, and end, on exact private staging and on the production website. For a Creator’s event, the agency Owner and Admins are told when it is added, starts, and ends, and the Creator is told when it starts and ends. For a staff member’s own event, that staff member is told when it starts and ends, and when the event belongs to an Admin, the Owner is also told when it is added; a Team Member’s or Team Leader’s own event never creates an “added” notice. Each notice appears in the recipient’s in-app notifications and, unless the recipient has turned calendar emails off, is also emailed through Resend from Aramingo’s notification address. The email’s subject names the change and the event title (up to 120 characters), and its message says which account added, started, or finished the event and asks the recipient to open their Aramingo notifications. For a Creator’s event, that account label includes the Creator’s username and sign-in email address, so the Owner and Admins receive the Creator’s email address in these messages; for a staff event, it is the staff member’s email address. Each notice is emailed at most once; a notice more than a day late is not emailed, a send Resend does not accept is retried after about 15 minutes, and email suppression is honored. D1 stores each notice’s event title, account label, phase, times, recipient, email state, and Resend message ID, deleted after 365 days and removed sooner for accounts that leave, plus each account’s calendar notification time zone and email setting. Calendar emails are on by default for staff and off by default for Creators, and each recipient can change this in the Calendar notification settings; in-app notices cannot be turned off. Resend’s own copies and logs follow the provider retention described in this policy.

What’s New release notes

On the production website, the public What’s New page can show notes about each production release. Aramingo drafts each note automatically from that release, using only short public notes written into the changes it contains, and a note appears only after the agency Owner reviews and publishes it. Only the Owner can see drafts and revise, publish, or withdraw notes; Admins, Team Leaders, and Team Members cannot. The public page shows only each published note’s release version, heading, lines, and published date. For each note, Aramingo’s D1 database also keeps a one-way digest identifying the release, its state and version number, its created, updated, published, and withdrawn times, and whether it was created and last changed by the automatic process or by the Owner, with the Owner’s internal Team ID; no name or email address is stored. Each change also writes a revision record with the same details. Withdrawing a note hides it but does not delete it, and notes and their revision records have no automatic deletion schedule; they are included in the nightly encrypted backups described below. None of these records is shown publicly.

Creator public pages — not offered

Aramingo does not offer Creator public pages (/@handle) or sponsor short links (/go/) on the website. These were planned but are not built, and none is offered on staging or on the production website. Aramingo’s database has tables set aside for a possible future version, but nothing is collected or stored in them. If this changes, this policy will be updated first.

Add to calendar

Where offered, calendar events and dated checklist tasks in Creator Studio and Team Portal have an “Add to calendar” menu. Downloading a calendar (.ics) file, which Apple Calendar and most calendar apps can open, creates the file in your browser from what is shown on screen; Aramingo does not store the file or send it anywhere. If you choose a Google Calendar, Outlook.com or Microsoft 365, or Yahoo Calendar link, your browser opens that provider’s website with the item’s title, time, and description in the link, and that provider handles the information under its own privacy terms. Aramingo adds no internal IDs, email addresses, or internal links to the link, and nothing is added to your calendar unless you save it there.

Conditional Owner Discord alerts

On Aramingo’s exact private staging and, once the Owner connects it, on the production website, Aramingo’s bot posts alerts for the agency Owner to channels in the Owner’s own private Discord server; the production website posts to its own separate channels. The Owner switches each type of alert on or off in the Team Portal and chooses whether it is sent right away or in a daily summary; every type is off until the Owner turns it on. Alerts are fixed sentences. Operational alerts carry no personal information: website deploys and backups, What’s New releases published on the live site with their version number and a link to What’s New, pull requests merged or waiting for the Owner’s decision, and business and cost alerts. On the production website, the business and cost alerts work the same way once the Owner connects Discord alerts; the invoice alerts also need the FreshBooks connection described below and the Owner’s email alerts switched on there (in the canary mode described below, only the canary Creator’s invoices are checked), and come from a daily check that sends invoice reminder emails there only if the Owner has also switched those on, and the sponsor-report alerts also need the Twitch Bot to be connected. Business and cost alerts say only that a FreshBooks invoice became overdue or was paid, that a stream with sponsor messages has ended and its report is ready, that the day’s automatic-caption budget is used up, that a Creator reached the daily clip limit, that a business inquiry arrived through the website form or a Creator’s Discord server (with only its category), or that the agency’s GitHub Actions spending this month passed a dollar level the Owner set (with that level and the month’s total so far), or that the website’s email sending reached 80% or 100% of its daily or monthly limit; they never include an invoice reference or amount, a customer, Creator, or sponsor name, or anything the person making an inquiry wrote. The GitHub Actions spending figures are the agency’s own costs, not personal information; while that alert is on, Aramingo checks them about once an hour. To send the invoice alerts, Aramingo also checks the FreshBooks invoice status of each assigned customer during its daily invoice check, and reads the first page of a customer’s invoice history only while the “Invoices paid” alert is on.

Alerts that involve people are sent only once this disclosure is published and a separate switch for them is turned on. On the production website, Creator-activity and security alerts, including the new-device sign-in alert, work the same way once the Owner connects Discord alerts and switches on alerts that involve people, and the new-device cookie described in the storage table is then set there as well. Team calendar alerts in a private agency channel may include a Team calendar event’s title (up to 80 characters) with its date and time; Creator calendar events are never named. Creator-activity and security alerts may include a Creator’s display name (up to 40 characters) and what happened, with a date: for example a sign-in (at most once per Creator per day), a sign-in from a new device, that files were uploaded, a calendar or onboarding update, a password, multi-factor, or sign-in email change, a Twitch Bot event, a Leak-Trace match, a security event on a Team account, or a Creator’s deactivation, reactivation, or Drive folder access. Website inquiries produce only the category-only business alert described above, not a personal-detail alert. Names and titles are cleaned before sending so they cannot mention anyone or add formatting. Alerts never include file names, document names, message or file contents, email addresses, passwords, or codes, and tools that work only in the browser are not tracked.

To send each alert once, Aramingo’s D1 database keeps a queue record with the alert type, its channel category, an internal delivery key, an internal Creator reference where relevant, dates, and delivery status; it does not store the alert text, names, or titles, and it looks up a Creator’s display name at the moment of sending. Queue records are deleted 30 days after they were created once they have been sent, skipped, or have finally failed. Aramingo keeps a Creator ID and date for 7 days so that a sign-in alert is sent at most once a day, and keyed digests showing that an alert was already sent, or that an invoice was seen unpaid, which are deleted when their window (up to about 400 days) ends. For new-device alerts, and only while that alert is on, a successful Creator sign-in sets a random cookie in that browser; Aramingo stores only a keyed hash of it, with the times it was first and last seen, for at most 20 browsers per Creator, and deletes each one 180 days after it was last seen. These records use Aramingo’s own identifiers and, for some alerts, the agency calendar event ID, pull request number, Twitch stream ID, or business inquiry they concern, or a GitHub Actions spending level and monthly total; only a pull request number, an inquiry’s kind, that spending level and total, or an email sending threshold appears in an alert, and the records themselves are not sent to Discord. Discord receives the alert messages and keeps them in the Owner’s server under its own policy.

Conditional in-app notifications

When enabled on exact private staging or the production website, authenticated Creator Studio and Team Portal accounts can view an in-app notification bell, unread count, and paginated history. The sources are Creator Shared Drive receipt and queue-clear events, where an eligible Creator sees their own events and an authorized Owner or Admin sees staff-eligible events, and, for the agency Owner only, the Creator status and Drive access notices described under Creator Information. Team Leader and Team Member accounts have no published Creator Drive event category. D1 keeps an opaque notification row identifier, an internal account or staff-principal recipient reference, a source-event reference, event kind, read or unread state, version, and lifecycle times; the visible label, state, time, and allowlisted folder link are assembled from the authorized retained source event. Opening a bell or history does not mark an item read; a recipient may explicitly change only their own read state. The notification record contains no file bytes, separate message body, provider credential or response, and the bell itself sends no direct message, push, email, or SMS; the Owner’s email and Discord notices described under Creator Information are sent separately. Notification history has a rolling 365-day visibility window measured from source-event creation; source cleanup is best effort on qualifying mutations rather than timed physical deletion, and deleting a source event or account removes linked notification rows. When this longer window starts, retained events from 90 to 365 days old may reappear for existing authorized recipients; already pruned events cannot be recovered. Changing read state does not extend source retention. This disclosure does not promise deletion of a Google Drive file or a separate backup archive.

Technical and operational information

Cloudflare and other service providers may process ordinary technical and security information needed to deliver and protect the site, such as IP address, browser or device information, requested page, referring page, request time, headers, access-control results, and error or abuse signals. Aramingo does not promise that ordinary provider security or access logs contain no personal information and does not state a provider retention period that the provider has not established.

How we use information

We use information to deliver and secure the website, remember requested preferences, authenticate authorized users, operate requested tools, prevent spam and abuse, review and answer inquiries, evaluate a potential agency relationship, maintain necessary business and security records, and comply with legal obligations. We do not use inquiry information for automated acceptance decisions or to train artificial-intelligence models.

Service providers

Cloudflare hosts and protects the site and provides the Worker, D1, and R2 services used by the application, and Cloudflare Web Analytics measures visits to the public pages of the production website, as described above. Workers AI and AI Gateway are separate conditional services used only for the explicitly selected cloud-transcription path described above. Read the Cloudflare Privacy Policy.

Where Cloudflare Turnstile is switched on (it stays off until Aramingo configures it), it checks that a person, not an automated program, is using the website inquiry form and Creator Studio’s requests for an email sign-in link, a password reset, or a sign-in email change, and Creator password sign-in after three failed attempts for the same username, including one that does not exist, or from the same network. It is never used for Google sign-in, passkeys, or two-step verification. The page loads Cloudflare’s Turnstile script from challenges.cloudflare.com, which may run a check in the browser; Cloudflare processes browser and device signals and the visitor’s IP address for that check under its own terms. The check gives the page a single-use token, and Aramingo’s server sends that token and the visitor’s IP address to Cloudflare to confirm it; Aramingo keeps neither the token nor the result. Read the Cloudflare Turnstile Privacy Addendum.

Resend receives the business recipient, sender, subject, purpose/template labels, and plain-text inquiry copy. Resend may retain message content and delivery records; its email and log retention is separate from Aramingo’s inbox retention. Resend states that stored data is held in the United States regardless of sending region, that email and log data on the Free plan is retained for 30 days, and that backups persist for 7 days. Those are provider statements, not Aramingo-enforced deletion or residency guarantees. The business email provider also receives and stores a delivered copy. Read the Resend data processing and retention information.

Google Identity Services verifies administrator Workspace identities and, only when configured, Creator Google identities. Google Drive would store Creator files only if Shared Drive upload is later enabled. These are separate Google services. Google Calendar would store Creator and staff events only if the Agency Team Calendar is separately enabled. Google Search Console gives Aramingo aggregate reports about how the public site appears in Google Search, as described above. Read the Google Privacy Policy.

Aramingo keeps encrypted offsite backups in a private Backblaze B2 storage bucket. They run on Aramingo’s exact private staging and, once the Owner switches them on, on the production website. Each night, a scheduled job backs up Aramingo’s complete Cloudflare D1 database, which can include account records, password hashes, encrypted MFA material, security logs, preferences, Creator onboarding answers, saved Trailer Maker presets, and the other application records described in this policy. It also backs up four kinds of files from R2 storage: Owner payment QR images, saved Trailer Maker background images, Creators’ My Brand kit logos, and, once Creators can upload them, Creators’ custom OBS overlay alert images and sounds. Twitch clip videos, Streamer.bot replay videos, and temporary Creator media processing files are not backed up. Files uploaded to Creator Shared Drive and pay-records copies saved to Google Drive are stored in Google Drive and are not part of these backups either. Aramingo encrypts all backed-up content with AES-256-GCM before it is uploaded, using a key that Backblaze does not hold. Backblaze can see only object names made of a fixed prefix, a date, and a snapshot time; content types and format labels; SHA-256 checksums; and a small receipt listing references, checksums, sizes, times, and the provider’s version number. Staging and production use separate buckets, separate access keys, and separate encryption keys. About 30 nightly backups exist at any time. Each is protected by Backblaze Object Lock in governance mode for 28 days, which blocks ordinary changes and deletion during that time; on staging, Aramingo’s own backup key can override the lock, so there it does not protect against misuse of that key; on the production website, the backup keys can only add or read backups and cannot override it, although, as with any governance-mode lock, the storage account’s owner still can. A storage rule then hides each backup and deletes it a day later. Information you erase from the application can therefore remain in encrypted backups for up to 30 days. If a backup is ever restored, Aramingo re-applies recorded erasures before the restored data is used, and a restore that cannot re-apply them does not proceed. Read the Backblaze Privacy Notice.

FreshBooks connection routes, Owner controls and a Creator invoice-viewing service work on exact private staging and, once the Owner sets up and connects FreshBooks for it, on the production website. Their presence or deployment does not mean an account is connected or OAuth is enabled. When enabled, only the authorized Owner deliberately connects the business and maps its customers to Creators. The integration requests profile-read, customer-read and invoice-read access. Creator invoice access uses the authenticated Creator’s active account/customer mapping, not an email match. The server reads bounded invoice references, dates, amounts and currencies; the Creator summary uses generic invoice labels, issue and due dates, outstanding amount and currency, and due or overdue status rather than exposing provider invoice references. Missing mapping or unavailable provider data is not a zero balance. The invoice-viewing service does not edit FreshBooks records, collect payments, or itself send email; the separately controlled email alerts described above may send invoice reminders, on exact private staging and, once the Owner switches them on, on the production website. Read the FreshBooks Privacy Policy.

The approved contact-management rollout provides one primary agency contact email and up to five additional emails when those controls are enabled. On deliberate Owner mapping, validated FreshBooks customer email initializes the primary only when agency contact is absent. Owner edits are preserved through refresh, resynchronization and remapping. Valid provider contact remains required; agency contact emails do not replace unavailable provider data. These contact details are separate from Creator sign-in identity and invoice authorization. They are not written back to FreshBooks and saving them does not send a message. These controls are available to the Owner once FreshBooks is set up and connected, on exact private staging or on the production website.

Aramingo’s server-side D1 records can include internal Creator and Owner identifiers, FreshBooks account/customer identifiers, assignment and contact state, record versions and lifecycle times. Agency contact records include original and normalized email addresses, additional-address order, and whether the contact was initialized from the provider or edited manually. Mapping and contact-change audit records contain internal actor and target identifiers, a fixed event type and time, not contact emails or provider payloads. Connection access and refresh tokens are stored in encrypted envelopes with key/version, nonce, issue/expiry and refresh-coordination metadata; readable credentials are not returned in the invoice or contact views. OAuth attempts also store session, callback and browser-user-agent derivatives, authorization and step-up state, phase/version, timestamps, transition fingerprints and encrypted temporary authorization or selection payloads. Connection records also note which website the connection was completed on. Admission records hold the runtime mode, target binding, generation and enabled state; attempts and refresh coordination retain their admission association. These are protected records, not anonymous data. Ordinary host and provider technical processing remains subject to the disclosures above.

The existing OAuth attempt contract stops use after five minutes and sets deletion eligibility 24 hours after that original expiry; a scheduled cleanup then deletes the attempt in batches. Physical cleanup requires a separately invoked bounded operation, removing at most 100 eligible attempts; it is not a timed deletion guarantee. Legacy deployment-attestation history and replay evidence have finite eligibility based on the original evidence and writer expiry plus 24 hours, with bounded authorized cleanup and dependency checks. The legacy contract retains a minimal protected pseudonymous target head—target binding, epoch, state, expiry and history-retention horizon—permanently, including after retirement, to prevent old authority being restored; retired heads do not authorize access. This legacy rule does not establish retention for a replacement operational-history store. Connection, mapping and contact lifecycle records have no fixed source-implemented deletion schedule. Agency contacts persist through mapping revocation and soft offboarding; removal through the existing dependency-ordered Creator purge is distinct from disabling access. Contact and mapping audit records follow the account-audit retention described below. Local disable is distinct from token clearing, record deletion and provider revocation: it cannot recall already-dispatched provider work or revoke FreshBooks consent. FreshBooks stays off on each website until the Owner completes its setup there: the protected FreshBooks configuration for that website, an Owner-authorized admission record, the FreshBooks switch, and the Owner deliberately connecting FreshBooks and mapping Creators. Any new operational-history storage requires its own verified access, data inventory and retention disclosure before activation; this notice does not establish that such storage is operating or extend existing retention periods.

When account email delivery is enabled, Aramingo sends a one-time welcome email after the first successful sign-in to a Creator or Team account, on exact private staging and on the production website. It goes only to that account’s sign-in email address, at most once per account, and is never retried; accounts that had already signed in before this email existed do not receive it. It has the subject “Welcome to Aramingo Agency” and a fixed plain-text message naming the account’s role, saying the first sign-in is complete, and asking the recipient to contact their Aramingo manager right away if it wasn’t them; it contains no name and no link. It is sent through Resend as described below, which receives the recipient address, the fixed sender, subject, and message, and purpose/template labels. D1 keeps a record for each account of when the email was attempted and sent and when the account had signed in before, with no automatic deletion schedule. There is no setting to turn this email off, but it is not sent to an address on Aramingo’s email suppression list.

On exact private staging and the production website, email alerts start disabled until the verified Owner explicitly enables a selected-Creator canary and may later enable all eligible accounts. When enabled, Aramingo may use Resend to send a FreshBooks invoice-due reminder on its due date and an overdue reminder weekly while the invoice remains outstanding, using the Creator's FreshBooks contact email and the verified Owner's Workspace email. Active Owners and Admins may receive an email when Creator content is loaded to the shared Drive. Resend receives the recipient, sender, subject, purpose/template labels, and plain-text notice. Billing notices include invoice reference, amount, currency, due date, and Creator display name; Drive notices include the Creator display name but no Drive file content. No invoice or Drive file body is attached. The Owner can disable billing reminders globally, per Creator, and for the Owner's own copies; each Owner or Admin can disable their own Drive notices. Creator accounts cannot disable billing reminders. This is not a claim that an accepted Resend send was delivered or read. On the production website, the Drive notices are sent as described, and FreshBooks invoice reminders are sent the same way, from the Aramingo Billing address billing@notify.aramingoagency.com with the same content and Owner controls, only once the Owner connects FreshBooks there and switches invoice reminder emails on for the production website.

Each account can turn off optional emails by category on its notifications page in Creator Studio or the Team Portal, or with the unsubscribe link in each optional email, which works without signing in. Creators can turn off What’s New emails; staff can also turn off Custom Request and Creator Update emails. Sign-in and security emails, invoice and billing emails, including invoice reminders, and required legal notices are always sent and cannot be turned off. Each account can also mute some on-site notices, such as Drive uploads, calendar, custom requests and What’s New; staff cannot mute incident alerts. D1 keeps each account’s email and on-site notice choices, each with where it was last changed (the notifications page or an unsubscribe link), a version number and when it was last changed, for as long as the account exists. The unsubscribe link carries a sealed, time-limited code instead of the email address or account ID; using it writes only that opt-out, and like the site’s other public forms it is rate-limited by IP address. When a new major or minor version is published on What’s New, Aramingo emails it to each active Creator, Admin and Owner account that has What’s New emails on, never to former Creators, and shows it as an on-site notice to each account that has not muted What’s New notices. D1 keeps one record of each release and, for each account and channel (email or on-site notice), a delivery record of the internal account reference, its state, attempts and times, including when the person read an on-site notice, without the email address or release text; delivery records are deleted 90 days after they finish. Resend receives the recipient, sender, subject and the published What’s New text with the unsubscribe link, and each email is kept in the email history described below.

When a Creator has two or more unpaid invoices that are due or overdue, Aramingo sends them one summary each Monday (Eastern Time) instead of separate reminders, listing up to 25 of those invoices with each one’s reference, amount, currency, due date, and whether it is due today or overdue, and the total for each currency; on other days, only an invoice due that day gets its own short reminder. The Owner gets a copy of each summary. After a Creator account is deactivated, Aramingo emails that former Creator one reminder a month while any invoice is unpaid, with a copy to the Owner, until the invoices are paid or the Owner turns these reminders off for them; for Creators who were already deactivated when these reminders began, they are off unless the Owner turns them on. D1 keeps that on/off setting while the account is deactivated and deletes it if the account is reactivated. The Owner can also mark an unpaid invoice as disputed: Aramingo then sends the Creator no reminders about that invoice, while the Owner’s own reminders and Discord invoice alert about it continue. D1 keeps each mark, with the FreshBooks invoice reference and the Owner and time, until the Owner removes it, including after the invoice is paid. Each mark, removal, and change to a former Creator’s reminder setting also adds a record of who made it and when, deleted after 400 days. Only the Owner can see these marks and settings. The Owner’s invoice page also shows when a Creator’s sign-in email differs from their FreshBooks contact email; that comparison is made when the page loads and is not stored.

When Creator email delivery is enabled on exact private staging or the production website, Aramingo uses Resend for sign-in links, password-reset links, security notices, and verified account-email transfer messages, separately from the inquiry-copy processing described in this policy. Resend receives the normalized recipient address, fixed sender and subject, plain-text message, and purpose/template labels. Sign-in, reset, and transfer-verification messages contain the complete one-time bearer URL; an advisory security notice contains only the reset-request page URL. After a proven transfer commit, Aramingo attempts separate change notices to the prior address when present and the new address; Resend receives those recipient addresses and fixed notice text without a bearer link. Resend says it stores message content, delivery logs, webhook payloads, and account records in the United States regardless of sending region. For the current Free plan, Resend says email and log data is retained for 30 days while the account is active and backups persist for 7 days. No message-content-storage exclusion is assumed. Read the Resend data processing and retention information.

When information may be disclosed

We disclose information to the providers described in this policy only as needed for their services. We may also disclose information when reasonably necessary to comply with law or valid legal process, protect the rights or safety of Aramingo or others, investigate abuse, or complete a business reorganization in which the recipient agrees to protect the information. We do not sell personal information or share it for cross-context behavioral advertising.

Cookies and functional storage

The four authentication cookies and the conditional new-device cookie have no Domain attribute and are host-only. The two Team cookies are conditional on the Team Portal flows described above, on exact private staging or the production website, and the new-device cookie is set only while the new-device Discord alert is on. The browser settings and optional D1 preference record are not cookies. No CSRF cookie exists.

Retention, expiry, and deletion

Browser preferences remain until you clear them or use the removal control below. The optional IP-derived D1 preference record becomes logically expired 90 days after its last update. Expired records are deleted when the preference route encounters them or when a successful preference update runs the expiry cleanup, and the removal control deletes the current public-IP record; logical expiry is not a guarantee that a row is physically pruned at that exact moment.

Inbox inquiries have a 180-day retention period measured from submission. Expired inquiries are excluded from inbox views and become eligible for bounded cleanup; physical deletion may finish later if cleanup is delayed or backlogged. Marking an inquiry read or archived does not restart that period. The agency Owner can also delete an inquiry from the inbox sooner, for example when you ask; it is then deleted at once, and only a record that an inquiry was deleted, without its contents, is kept until its 400-day cleanup. This limit does not delete an email copy or immediately erase encrypted backups; backup handling is described separately in this policy. Aramingo has not adopted a fixed deletion period for genuine inquiries in business email. We keep those copies only while reasonably needed to respond, evaluate a potential relationship, maintain necessary business records, resolve disputes, or meet legal obligations, and we may delete or anonymize information that is no longer needed.

Creator and administrator sessions stop authorizing access at their stated expiry and may be removed opportunistically when sessions are created. Authentication rate-limit windows last 15 minutes, an hour, or a day and are no longer used after the window closes; each row is deleted, up to 100 at a time, during a later sign-in or form submission at least 30 minutes after it last changed (for hourly and daily limits, at least 30 minutes after the window ends), so on a quiet site a row can stay longer. Five-minute challenges and ten-minute Creator email sign-in and password-reset links become unusable at expiry or use. A scheduled cleanup then deletes Creator sign-in challenges and email sign-in links 30 days after they expire; password-reset links follow the cleanup described below. Active MFA and passkey metadata remain until reset or revocation. The account audit log (account and Creator audit records, including those described above as kept there) is deleted 400 days after each event by a scheduled cleanup that runs in batches, so shortly after rather than exactly at that time. Other audit records not given a period elsewhere in this policy have no fixed source-implemented deletion period and are retained while reasonably needed for access, security, contractual, or legal purposes.

Hash-backed sign-in-link rows are deleted 30 days after they expire by a scheduled cleanup that runs in batches, so shortly after rather than exactly at that time. Password-reset-token rows are eligible for bounded deletion 24 hours after expiry or use during later qualifying Creator email activity, and security-notice markers after 7 days, with at most 100 eligible rows of each kind removed per pass. Aramingo application tables do not keep raw one-time bearer URLs or email bodies. Rate-limit and audit records follow the separate security retention described above. Resend's message and backup retention is described in the service-provider section. On exact private staging and the production website, an eligible Creator or Team Member/Leader can request a verified login-email transfer; an authorized Owner or ordinary Admin may initiate one for an eligible Creator or Team account, but cannot complete it for the recipient or transfer a privileged Owner/Admin identity. We attempt to send a single-use verification link to the proposed new address; the link contains a complete bearer URL including its fragment. Resend receives that URL, the recipient address, and message metadata, but an accepted-send result does not prove inbox delivery. Creator initiation requires a fresh password plus authenticator proof when enabled; completion requires the signed-in account and the new-mailbox link. Team completion requires the intended signed-in account and independently signed, same-nonce Google proofs for the current and proposed Workspace identities. A proven successful transfer invalidates the old application session. After commit, we attempt separate non-authorizing notices to the prior address when present and the new address; those notices contain no bearer link. D1 stores a digest of the bearer token, bounded intent state, internal actor and target references, versions, email and Google-subject binding data needed for the short-lived transfer. The immutable pseudonymous success audit keeps internal actor, target, and intent references; purpose-separated keyed digests of prior and new normalized email (nullable prior Creator email) and, for Team, prior and new Google subjects; resulting version; and occurrence time. The audit has no raw email, credential, or bearer URL, and a digest is not permanent identity authority. The application does not store the raw link, Google credential, password, or authenticator code. An intent stops authorizing use after ten minutes. Expired pending intents may be removed on a later qualifying mutation to permit a new attempt; consumed intents have a 24-hour best-effort cleanup target, at most 100 rows per pass. Pseudonymous success audit has a 400-day best-effort cleanup target of at most 50 rows per later qualifying mutation, not a timed deletion guarantee. Backups may retain earlier copies under their separate lifecycle. Resend's current U.S. Free-plan email/log 30-day and backup 7-day retention disclosures above apply to these messages. This feature does not connect a provider account or change a FreshBooks contact address.

For email alerts, D1 stores the activation mode and optional internal canary Creator ID, per-alert preferences, associated internal Creator IDs, recipient address, one-way dispatch identifier, claimed/accepted state, optional Resend message ID, and timestamps. Accepted sends may also create a D1 Resend receipt and email-history/message/delivery-event metadata; receipt rows become eligible for bounded cleanup after 30 days. A scheduled cleanup that runs in batches deletes each alert’s dispatch record, including its recipient address, 90 days after the alert was sent or attempted, and the email history of every email the site sends (each message record and its delivery events) one year after the message’s last delivery event; a provider suppression notice that is not tied to a message is deleted one year after it arrives. Short-lived delivery bookkeeping for alert retries and the daily invoice alerts, which holds no address or message content, is deleted 2 and 7 days after its last change. Alert preferences and the email suppression list itself have no automatic deletion schedule. D1 does not store the alert message body, a FreshBooks token, or Drive file content. Access and deletion requests may be made through the contact methods below. Resend retains message content and delivery metadata under the provider retention described above. On exact private staging and the production website, an individually assigned Team Leader or Admin may view Owner email-history metadata, including sender and recipient email addresses and suppression-directory entries, without authority to change suppression state.

Deactivating a Creator account ends all of its sessions and blocks every sign-in method while it is deactivated; its Google and passkey sign-in methods stay attached but cannot be used, outstanding sign-in links and challenges cannot be completed, and reactivating it restores sign-in without a new invitation. On Profile Settings, a Creator can choose Request My Data or Delete My Account. Each only sends a request: nothing is exported or deleted automatically. The agency answers by email after confirming the request with the Creator, and may keep records it needs for security, contractual, or legal reasons. Each request writes a security audit record of its type and time, without any message; creates an in-app notice for the Owner with a fixed sentence and no Creator details, kept for 90 days; and sends an email through Resend to hello@aramingoagency.com with the Creator’s username, name, sign-in email, the time, and a request ID. A Creator can send one request of each kind per day (UTC). There is no fixed account-deletion schedule. The Connected Accounts section of Profile Settings lists the Twitch connection, the Discord bot where it is enabled, and the Streamer.bot key, with their dates; disconnecting one there uses its usual disconnect described in this policy and also writes a security audit record of its type and time. A privacy request may still be made, and Aramingo will evaluate it subject to security, contractual, and legal reasons to retain particular records.

When a Creator asks for a copy or deletion, the agency Owner can act on it in the Team Portal after confirming the request with the Creator. Download This Person’s Data gives the Owner one data file with the Creator’s account, profile, saved settings, connected accounts, request history, and activity records, and a list of their stored media by name, type, size, and date, without the media itself; the Owner sends it only to the email address on the account. The file never includes passwords or sign-in and security secrets, the Owner’s private notes, or other people’s details, such as fan names, inquiry contacts, or chatter names. Delete This Person’s Data works only on a deactivated account. It ends the account’s pending jobs, disconnects Twitch and revokes Aramingo’s Twitch access, removes the Discord bot and its scheduled events from the Creator’s server, deletes the Creator’s Agency Calendar events, erases their Creator Profiles, deletes their stored media and personal records, and replaces the account’s username, names, and email addresses so that it no longer identifies them; a deleted account can never be reactivated. For security, contractual, and legal reasons, Aramingo keeps invoice and billing records, content-free audit records and short labels until their 400-day cleanup, a record that the deletion happened, and any existing entries for the Creator’s email addresses on the email suppression list, so that blocked email stays blocked. It does not delete the files in the Creator’s folder in the agency’s Google Drive; the Owner removes the Creator’s access to that folder. Copies that providers keep under their own terms, such as email copies at Resend, messages already posted to Discord, clips on Twitch, and records in FreshBooks, are not removed by it. If a nightly backup is restored later, Aramingo deletes the Creator’s data again before the restored data is used.

Creators and staff can each add an optional profile to their own account: a display name of up to 80 characters, a contact email, and a profile photo. The display name and photo are shown to the person themself; to the agency’s staff wherever a Team Portal list they can already open shows that person; and, for staff members’ profiles, to signed-in Creators. A Creator never sees another Creator’s name or photo this way. The contact email is shown only to the person themself on their own profile settings. It is not their sign-in email or an invoice contact, and the only email Aramingo sends to it is one confirmation link, when the person asks for it. Until the address is confirmed, D1 keeps the new address with a one-way hash of the confirmation link, never the link itself, and both are deleted 24 hours after the request. A person can choose a JPEG, PNG, WebP, AVIF, or HEIC/HEIF picture that their browser can open; animated pictures and SVG files are refused. The browser crops it to a square, resizes it to at most 512 × 512 pixels, and converts it to WebP or PNG, which removes embedded details such as camera, location, and text. Only that converted copy, of up to 512 KB, is uploaded; the original file is never sent or stored. Aramingo checks the uploaded copy and stores it privately in Cloudflare R2, shown only through the signed-in portals. A replaced or removed photo is deleted from storage, and so is an upload that is not finished within about an hour. Profile photos are not part of the nightly backups, and restoring a backup keeps the current profiles rather than older ones. Each change adds a record of who made which change and when, without the values, deleted after 400 days. A Creator’s profile is included in Download This Person’s Data and deleted by Delete This Person’s Data; a staff member’s profile and photo are deleted when they are offboarded.

On exact private staging and the production website, an authorized Owner or Admin may select one verified Creator account and deliberately import one row from a locally selected historical Typeform CSV. The CSV may include sensitive personal answers, including race or ethnicity, sex-life, or sexual-orientation information. The browser parses the file locally; the application receives only the 28 selected answers and optional original submission-time text, never the CSV file, Typeform token, source-row name hint, or unselected rows. D1 stores those answers, the source label, internal Creator and staff references, status, optimistic version, and lifecycle times. The Creator may read and correct their linked answers; authorized Owner/Admin staff may perform an audited read, correction, archive, or immediate answer-body erasure; and, where Creator Information is enabled, Team Leaders and Team Members may perform an audited read, and correct the answers only with an editor grant from the Owner or an Admin, as described under Creator Information; the audit records of these changes also note the acting staff member’s role. Active answers are kept only while the Creator relationship and stated purpose continue, with an annual necessity review recorded by the authorized operator; this is an operational commitment, not an automatic deletion timer. Archive unlinks the Creator and immediately stops Creator access. Archived answer bodies become inaccessible through the ordinary Creator view and are logically expired 30 days after archive; a bounded cleanup attempts physical removal, but no exact physical deletion time is promised. For withdrawal or an approved early erasure request, staff can replace the selected active or archived answer body and submission text with an empty content-free tombstone immediately after a confirmed, version-fenced operation, including when the Creator account is disabled; protected content-free attribution remains temporarily for audit. Content-free mutation and staff-access audit records and erasure tombstones target cleanup after 400 days. The authorized operator must dispose of the local source CSV after verified import or within 24 hours, whichever comes first. Aramingo does not claim to delete a separately held Typeform source copy through this feature. Answer-bearing backups follow the encrypted offsite backup rules described under Service providers: they are kept for up to 30 days, and a restore re-applies recorded erasures before restored data is used. Consent and withdrawal evidence is maintained outside this application, and a Creator may use Request My Data or Delete My Account on Profile Settings, or the contact methods below, to request access, correction, withdrawal, or deletion subject to applicable obligations. The feature does not import a CSV automatically.

Team and pending ordinary-Admin MFA cookie state stops authorizing access at eight hours and ten minutes respectively, or sooner when cleared or invalidated. Principal, role, and access-grant records have no fixed source-implemented deletion schedule. Staff and staging-Admin grant audit pruning is best effort: it targets 400 days, 100 events per grant, and 5,000 events overall, deleting at most 50 old rows during a qualifying mutation. Those are cleanup targets, not a promise of deletion at an exact time. Revocation and authorization-version changes cause existing Team cookie state to fail revalidation even if the cookie has not yet expired.

Security

We use reasonable technical and organizational safeguards, including server-side authorization, restricted staff access, hashed passwords and session tokens, encrypted authenticator secrets, keyed security identifiers, expiring authorization, bounded input, and fail-closed feature gates. No online transmission or storage system can be guaranteed completely secure, so send or select only information needed for the requested service.

Your privacy choices

You may ask whether we hold information about you, request a copy, ask us to correct inaccurate information, or request deletion. Depending on where you live, applicable law may provide additional rights. To protect your information, we may verify a request through the email or account associated with it. We will respond within the period required by applicable law and will not treat you unfairly for making a privacy request.

International processing

Our providers may process information in the United States or other countries where they operate. Privacy protections may differ from those in your location. Where applicable law requires transfer safeguards, we use safeguards available through our providers or another legally recognized method.

Third-party links

The website may link to services we do not control. Their privacy practices are governed by their own policies, which you should review before sharing personal information.

Changes to this policy

We may update this policy when the site, providers, or practices change. We will post the revision here and change the effective date. If a change materially affects previously collected information, we will provide any additional notice required by applicable law.

This October 26, 2026 update describes the optional profile each account can add, with a display name, a contact email, and a photo, and how long each part is kept. The October 25, 2026 update described the optional email and on-site notice choices each account can make, the unsubscribe link in optional emails, What’s New release emails and notices and their delivery records, the Owner’s Discord alert when a release is published, and that incident email is sent whenever the site’s Team Portal email is enabled. It also described Download This Person’s Data and Delete This Person’s Data, which the Owner can use to answer a Creator’s request for a copy or deletion, and what the deletion keeps. It also described the Owner deleting a website inquiry before its 180-day period ends, and that staff offboarding ends the person’s sessions. It also described the Monday invoice summaries, the monthly reminders to former Creators and the Owner’s switch for them, and the Owner’s disputed-invoice marks and their records. It also wrote every file size in the website’s units, where 1 MB is 1,024 KB. The October 24, 2026 update described the site announcements the agency Owner can show on the public website, Creator Studio and the Team Portal, the records of each save and early end kept for 400 days, and the browser-only record of a dismissed announcement. It also described the Request My Data and Delete My Account requests a Creator can send from Profile Settings, Sign Out of All Devices, and the Connected Accounts section there. It also said that Caption Studio can use the cloud transcription service automatically for Creators when their device cannot make captions itself, unless they turn off “Use Cloud Captions When This Device Can’t”. It also described the monthly usage limits for cloud captions and Twitch replay clips, and their use records and the Owner’s change log, each kept for 400 days. The October 23, 2026 update described the optional Shared-Device Mode for Creator projects and the control that removes a Creator’s saved work from a browser, and says that the email-sending-limit alert, which is never emailed, also appears as a category-only Owner Discord alert. It also described the time zones each account can choose for its emails, and that Creators can see their own Creator Profile’s time zone. It also raised the cloud transcription limit to $2 of provider cost and 769 requests a day, and described the clip folder a Creator can choose and their export notes. The October 21, 2026 update described Creator Drive’s limited verification read, the Creator-linked upload checksum and its existing record and backup retention. It does not attest to deployment or change the existing activation controls. The October 19, 2026 update describes conditional Standard Procedure contents, role assignments, earlier versions, account references and bounded change-event cleanup, and the separate browser-only account-scoped Favorites and Recent tool lists and their controls; it does not enable either feature. The October 18, 2026 update described conditional Team Portal clock-correction requests, staff offboarding and quarterly access-review reminders, and operational incident designations, notices and conditional staff emails, including their data fields, access limits and bounded cleanup periods. The October 17, 2026 update described the Google sign-in code cookies, the limit counters for the inquiry form and saved site preferences, Cloudflare Turnstile on the inquiry form and Creator sign-in pages, and the daily and per-staff email limits; it also adds Thumbnail Maker designs, My Templates, and more editing tools to the projects kept on the Creator’s device, explains that the website asks the browser to keep them, and explains that Trailer Maker may save a trailer in the browser before downloading it; and it describes staff-made Leak-Trace copies and their Owner-only log, the Owner’s access log, and staff notices when a Creator updates their information. The October 16, 2026 update described the My Brand kit and its logo uploads, explained that editing-tool projects stay on the Creator’s device, kept separately for each signed-in Creator, and set deletion periods for older data: Creator sign-in challenges and email sign-in links 30 days after they expire, email history one year after a message’s last delivery event, email alert dispatch records 90 days, finished Twitch clip job records 30 days, and the account audit log 400 days. The October 15, 2026 update described the new Creator Information access rules: Team Leaders read all active Creator profiles except parts turned off for them, Team Members read only assigned or granted profiles or all Creators if allowed, and Team Leaders and Team Members change onboarding answers and content pricing only with an Owner- or Admin-given editor grant. The October 14, 2026 update described the What’s New editorial records kept for production release notes, clarifies that Creator public pages and sponsor short links are not offered, and states in each affected section and storage row that Team and Creator features already listed as working on the production website do so there. The October 12, 2026 update described Documents & Links, the links and Google Drive documents the agency assigns to Team accounts and Creators, on staging and the production website, corrects section headings and storage-table labels that still described features as working only on private staging, explains that the Owner’s Creator-activity, security, and business Discord alerts and the new-device cookie can work on the production website once the Owner switches them on, explains that FreshBooks invoice reminder emails can be sent on the production website once the Owner switches them on, and explains that cloud caption transcription can work there for Creators, the Owner, and Admins only. The October 11, 2026 update explained that the Twitch Bot, Streamer.bot, OBS overlays, the Owner’s Discord alerts that carry no personal information, and the Owner’s GitHub pull-request history can work on the production website once the Owner connects each of them, that Creator-activity and security alerts and the new-device cookie stay off there, that the FreshBooks connection and the invoice information read from it can work on the production website once the Owner sets it up, while invoice reminder emails stay off there, and that production backups will include Creators’ custom OBS overlay alert images and sounds. The October 10, 2026 update explained which Creator Studio and Team Portal features work on the production website once the Owner switches them on, that Creator Studio is then open only to Creators on its access list, and which features stay off in production; describes the first-sign-in welcome email and the Agency Calendar’s event notices and emails; moves Drive upload and access notices, Drive email alerts, and Resend delivery and suppression records to the production website; and updates the affected descriptions and storage rows. The October 9, 2026 update, for the public production website, added Cloudflare Web Analytics on the public pages and Google Search Console, explained that on the production website the inquiry inbox opens only with the Team Portal, and removed the remaining reference to the former inquiry provider. The October 8, 2026 update described conditional browser-local AI processing, on-demand model downloads and the device’s model-only cache, and distinguished local transcription from the separately selected cloud service. The October 6, 2026 update replaced FormSubmit inquiry delivery with Aramingo’s authenticated Business inquiries inbox, an attempted Resend email copy, and category-only Discord alerts; described 180-day inbox retention separately from mailbox and backup copies; and removed use of the form’s browser-stored cooldown timestamp. The October 5, 2026 update added deactivation for Creators who leave the agency, staff changes to a Creator’s sign-in email, optional sharing of a Creator’s Google Drive content folder, and related Owner notices; adds Streamer.bot replay uploads, saved polls, the agency Owner’s raid train, and Twitch Bot follower, subscriber, and bits milestones; adds the creator Discord bot that a Creator can add to their own Discord server; describes more precisely who can reach the weekly pay records and when they are removed; and is effective on the date shown above. The October 4, 2026 update added the Twitch Bot’s growth stats, Creator Information (Creator Profiles, content pricing, and Team Member access to a Creator’s profile), and Team work history (who can see staff clock times and create planned shifts, staff time-zone confirmation, and weekly pay records kept in the agency’s Google Drive), and raised the whole-file limit for optional automatic captions to sixty minutes. The October 3, 2026 update let a Creator’s going-live Discord alert mention one role the Creator chooses and added the Metadata Stripper’s saved credit. The October 2, 2026 update added the Twitch Bot’s OBS overlays and noted that a Streamer.bot clip keeps a copy of a scene layout only if that scene has one. The October 1, 2026 update clarified the optional manually entered speaker and calendar-date attribution for saved Twitch Bot quotes, without changing retention. The September 28, 2026 update added the Twitch Bot raid shield, command variants, automatic commands, and Streamer.bot connection, staff sends to Creator Drive, the Owner’s Discord alerts, staff visibility of Creators’ last sign-in dates, and Creators’ public pages and sponsor short links, and listed more precisely which Twitch Bot records are deleted on a schedule, to the privacy policy revision dated September 27, 2026.

Contact us

Aramingo Agency is responsible for the public-site and application information described here. For privacy questions or requests, email hello@aramingoagency.com.