Privacy Policy

1. Who we are

The service at oraglegpt.org (the "Service") is operated by:

GPT LLM ORAGLE Ltd. Liability Co.
A Wyoming close limited liability company (filing ID 2026-001932735)
Registered office: 30 N Gould St, Ste N, Sheridan, WY 82801, United States

In this policy, "we", "us", "our", and "the Company" mean that legal entity. Privacy enquiries go to privacy@oraglegpt.org. We do not identify individual officers or staff in this policy; the Data Protection Contact is reachable only through that mailbox.

• EU / EEA representative (GDPR Article 27). The Company has no establishment in the EEA. Where Article 27 requires a representative to be designated, the designation will be published on this page and notified to affected customers before it takes effect. Until then, send Article 27 enquiries to privacy@oraglegpt.org.
• UK representative (UK GDPR Article 27). The same applies for the United Kingdom.
• Supervisory authority for complaints in the EEA or UK. You may complain to the supervisory authority of your habitual residence, your place of work, or the place of the alleged infringement.

2. What the Service does, in privacy terms

GPTpost is a multi-tenant social media management platform. Each customer gets an isolated tenant (also called a workspace). Inside a tenant, authorised users:

• connect social accounts belonging to the customer or the customer's clients, using OAuth or provider-issued credentials;
• compose, approve, schedule, and publish content to those accounts;
• work comments, mentions, reviews, and direct messages in a unified inbox. In this build the inbox is fed by the customer, not by the platforms. Conversations reach GPTpost because an operator or the customer's own integration submits them to the ingest API. GPTpost does not read messages, comments, mentions, or reviews from Facebook, Instagram, Threads, or any other connected platform, and replies composed in the inbox are not delivered to a platform;
• record analytics and engagement metrics. These are likewise submitted to the metrics ingest API by the customer; this build pulls no insights or analytics from any provider API;
• optionally run AI assistance over their own content;
• optionally export data through the API, webhooks, and MCP interfaces.

That shape drives two different legal roles, described next.

3. Our two roles: controller and processor

Social platforms (Meta, TikTok, X, LinkedIn, Google/YouTube, Pinterest, Reddit, Mastodon instances, and others) are independent controllers of the data they hold. Their own policies govern what they do with it.

4. Data we process

4.1 Account and identity data (we are controller)

• Email address, display name, and workspace/tenant name.
• Password verifier (salted hash - we never store a plaintext password).
• Multi-factor authentication material: TOTP secrets, recovery codes, and WebAuthn / passkey public-key credentials and credential IDs.
• Session records: an opaque session token stored in the orbitpost_session HttpOnly cookie, token hash, absolute and idle expiry, roles, and the tenant the session is bound to.
• Enterprise identity attributes when the customer configures SSO: OIDC or SAML assertions (subject identifier, email, name, group claims) and SCIM user and group provisioning attributes.
• Role and permission assignments (RBAC/ABAC), approval authority, and step-up authentication events.

4.2 Connected social account data (we are processor)

When a user connects a social account, we store, per connection:

• the OAuth access token and, where the provider issues one, the refresh token, both held in an encrypted envelope, never returned by the API, and never written to logs;
• the granted scopes, the token expiry, and the token refresh state;
• the provider account identifier (page ID, IG professional account ID, channel ID, board ID, subreddit or profile handle, Mastodon instance and account, Telegram chat ID, and so on);
• the display name, avatar URL, and connection metadata needed to render the account picker, as supplied when the account is connected or, for Reddit and Snapchat, as returned by that provider's identity endpoint;
• connection health status and the timestamp of the last check. Most health checks read only the stored credential and its expiry. TikTok health checks also call its creator-info endpoint to obtain the creator's current posting options; an authentication refusal marks the connection as requiring reconnection, while a transient provider error is recorded separately.

The connectors in this build are publish-only. Every call the Service makes to a social platform is an OAuth authorisation, token exchange or refresh; a publish call; an identity lookup at connection time for connectors that resolve the provider account automatically; or TikTok's creator-info query during a health check and immediately before a Direct Post. There is no message, comment, mention or review fetcher, no insights or analytics call, and no delete, hide, like or moderation call for any platform. The "What the connector does" column below describes only that, and where the registry requests a scope wider than the connector exercises, the row says so.

Most of the rows below cannot be connected in this release, so no token of theirs is stored and no scope of theirs is requested of anybody. Today an account can be connected only to Facebook Pages, Instagram Professional, Threads and TikTok through OAuth, and to Bluesky, Telegram, Discord and WordPress using a credential the customer supplies. For every other row the connector has no authoritative account-identity resolver in this build, or a provider-approval policy blocks it, so the authorisation flow refuses to start. Those rows are published in advance so that this policy is already correct when a connector is enabled. GET /api/v1/capabilities reports the live answer per provider.

Where a provider requires a dependency permission that the connector does not exercise, the row names that dependency and explains it. The table is republished whenever the live connector registry changes so that the consent screen, implementation, and policy remain aligned.

We do not use social platform data for advertising, profiling of platform users, credit or eligibility decisions, model training, or resale. Platform data is used only to provide the features the customer has enabled in their tenant, and it is deleted on the triggers described in Data Deletion Policy.

4.3 Published content and scheduling data (we are processor)

Drafts, per-network variants, campaigns, approval requests and decisions, schedules and recurrence rules, RSS/Atom-derived items, CSV bulk-import rows, uploaded media and its derivatives, brand assets, templates, usage-rights records, and the immutable publication attempt log (request, provider response or error, provider post identifier, timestamps).

Publication attempts are retained as an append-oriented audit record because they are the only reliable evidence of what was sent to a provider and when.

4.4 Unified inbox, direct messages, and CRM data (we are processor)

How conversations get here. The unified inbox holds conversations that the customer submits to GPTpost: an operator enters or pastes them, or the customer's own integration posts them to the inbox ingest API (POST /api/v1/inbox/ingest). This build does not read messages, comments, mentions, or reviews from a social platform, and it does not send replies to one. There is no provider inbox fetcher in the Service, and an outbound reply job has no live provider adapter, so a reply composed here stays in the tenant unless the customer's own systems carry it onward. Where the customer submits conversations that originated on a platform, the customer is responsible for having obtained them lawfully.

On that basis we store:

• comments, replies, mentions, notes, reviews, and questions;
• direct and private messages, including the message body, attachments, timestamps, and the sender's handle, user ID, display name, and avatar as the customer supplied them;
• canonical contact, conversation, case, routing, SLA, moderation, and assignment records derived from the above;
• outbound replies your team composes in the Service.

DMs are sensitive. They are tenant-scoped, encrypted at rest as part of the application state, visible only to users the customer authorises, and subject to the retention rules in section 9.

4.5 Analytics and listening data (we are processor)

Metric observations (impressions, reach, engagement, video views, click counts, follower counts, and similar), competitor and listening records the customer configures, attribution records, and generated reports.

How metrics get here. As with the inbox, metric observations are submitted to GPTpost by the customer, through the metrics ingest API (POST /api/v1/analytics/observations). This build makes no call to any provider's insights or analytics API, so nothing in this section is pulled from a platform by us. Where the customer submits figures a platform produced, the platform has normally aggregated them already; where a submitted record contains a per-user breakdown, we store only what was submitted and we do not attempt to re-identify individuals.

4.6 AI processing data (we are processor)

The Service can send tenant content to an AI model provider that the customer configures in their own tenant (settings/ai-providers). When an AI feature runs:

• the agent's system prompt, the user input, and any retrieved tenant knowledge citations are combined into a prompt and sent to the configured model provider over TLS;
• we store the agent run record: a hash of the input rather than the raw input where the run is blocked, the generated output, the model and provider identifiers, the prompt version, knowledge citations, tools requested, token usage, and cost;
• tenant policy controls are enforced before the call: allowed providers, allowed models, allowed tools, maximum output tokens, monthly budget, declared data region, and whether autonomous public actions are permitted;
• prompt-injection heuristics and content filters run on the input, and blocked runs are recorded with a reason and are not sent to the provider;
• where a customer requires human review, AI output is held behind an approval boundary and is not published automatically.

Supported provider kinds are OpenAI, Anthropic, Google Gemini, any OpenAI-compatible endpoint, and a local fixture mode that calls nothing. Which provider, if any, is enabled is a per-tenant decision made by the customer. Whether a given provider trains on submitted data is governed by that provider's own terms; customers must satisfy themselves before enabling one. See Subprocessors.

4.7 Billing and metering data (we are controller)

Plan, entitlements, subscription state, seat and usage counters, invoices, and paid-social spend records the customer imports.

Card data never reaches our systems. We do not store card numbers, expiry dates, or security codes. Where a paid plan is settled by card, the payment is handled by a PCI-DSS compliant payment processor; where it is settled by invoice, we hold only the billing contact and the invoice record. Any payment processor we engage is added to our Subprocessors page before it begins processing, with the notice period described there.

4.8 Technical, security, and audit data (we are controller)

• IP address and the validated forwarding chain, user agent, request method and path, response status, latency, and correlation identifiers.
• Authentication events, step-up events, failed logins, lockouts, and session lifecycle events.
• The tenant-scoped audit log: who did what, to which record, when, and from which session.
• Job, scheduler, outbox, webhook delivery, and backup and restore events.
• Error diagnostics. Secrets, tokens, and credential fields are redacted before they reach logs or diagnostics endpoints.
• When a social platform rejects a request, we store the HTTP status, the platform's own error code, and a single bounded line of its error message. We do not store the platform's response body, because a platform frequently echoes the request back inside it. A platform's error message can still quote a short fragment of the content it rejected; that fragment is kept no longer than the publication log above and is removed by a deletion request that identifies it.

4.9 Website and support data (we are controller)

Pages viewed on the public site, form submissions on site/contact and site/support, and the content of support correspondence.

5. Where the data comes from

• From you, when you register, configure a workspace, upload media, or write to support.
• From the customer's users, when they use a tenant.
• From social platforms, when you authorise a connection: the OAuth token response, and the account identity and profile metadata listed in section 4.2, read once through the provider's own API at the moment you connect. After that, the only thing a platform returns to us is the result of a publish attempt. No inbox item and no analytics figure comes from a platform. This build has no message, comment, mention, review or insights fetcher, and no inbound webhook receiver of any kind, so no platform delivers anything to the Service on its own initiative. Sections 4.4 and 4.5 say how inbox and analytics records actually get here.
• From feeds and files you configure: RSS/Atom sources and CSV imports.
• Automatically, from your browser or API client: cookies, session data, and request telemetry.

6. Why we process it, and our legal bases (GDPR Article 6)

About the two email rows. They are stated as legal bases, not as product features, and it matters which. The Service contains no mail client. There is no SMTP or mail-provider code anywhere in the application, no template, no send queue and no unsubscribe endpoint: no email is generated, addressed or despatched by this software under any circumstance, including a security event or a completed deletion. Anything you receive from us was written and sent by a person from a mailbox at oraglegpt.org, to an address you gave us, and it is that human correspondence the two rows above cover. We hold no marketing list in the product, and nothing in the product can add you to one. See Data Deletion Policy section 9.1 for the same statement applied to deletion notifications.

For tenant data where we act as processor, the customer determines the legal basis. Customers must have a lawful basis for ingesting inbox messages, DMs, and contact records, and for any outbound messaging they send through the Service.

7. Who we share data with

• Social platforms you connect. We send only what is needed to perform the action you requested: the post text, the media URL, and the token that authorises the publication. Nothing else is sent. Because the connectors are publish-only, no reply, comment, moderation action or deletion is ever sent to a platform from the inbox.
• Subprocessors. Infrastructure, storage, email delivery, payment, error monitoring, and AI model providers. The current list, with placeholders where a vendor is not yet chosen, is in Subprocessors.
• Your own destinations. Webhooks you register (delivered with an HMAC-SHA256 signature and timestamp headers), API clients you authorise, MCP clients, and data exports you initiate.
• Professional advisers, auditors, and insurers, under confidentiality.
• Acquirers, in a merger, acquisition, or asset sale, subject to this policy.
• Authorities, where we are legally required. We will notify the affected customer unless legally prohibited.

We do not sell personal information, and we do not share it for cross-context behavioural advertising.

8. International transfers

The Company is established in the United States. Data may be processed in the United States and in any region where a subprocessor operates.

• Primary hosting region: Germany, European Union. Application hosting and the primary database run at Contabo GmbH in Germany. Object storage for uploaded media is run by the Company itself on that same German infrastructure, so it is not a transfer to anyone and no United States storage provider is engaged. AI processing, when a customer enables it, runs at Anthropic or OpenAI in the United States. See Subprocessors.
• For transfers of personal data out of the EEA, the UK, or Switzerland, we rely on the European Commission Standard Contractual Clauses (2021/914), incorporated by Data Processing Addendum, together with the UK International Data Transfer Addendum and the Swiss amendments, and on supplementary technical measures (encryption in transit, encrypted application state, key separation, access control, and secret redaction).
• Customers can declare a required data region in their tenant AI policy, and we enforce that declaration at the AI call boundary. We do not currently offer a contractual guarantee that every subsystem is pinned to a single region, and we will not claim one we cannot keep. If regional residency is a requirement for you, write to dpa@oraglegpt.org before you rely on the Service.
• Adequacy decisions are relied on where one exists for the receiving country.

A copy of the transfer safeguards is available from privacy@oraglegpt.org.

9. How long we keep data

Retention periods marked as defaults are set per deployment through the environment (ORBITPOST_INBOX_RETENTION, ORBITPOST_PUBLICATION_RETENTION, ORBITPOST_ANALYTICS_RETENTION, ORBITPOST_AI_RUN_RETENTION, ORBITPOST_SECURITY_EVENT_RETENTION, ORBITPOST_SESSION_RETENTION, ORBITPOST_JOB_RETENTION, ORBITPOST_OUTBOX_RETENTION, ORBITPOST_ARTIFACT_RETENTION) and are enforced by an hourly sweep in the scheduler. They are not yet configurable per tenant from inside the product. Where a legal hold applies, retention is extended until the hold is released.

Backups we do not write. The 90 day figure above is enforced for the backup and export files the Service itself creates. The Service does not take database backups of its own. If your deployment is additionally backed up by your infrastructure provider, by a volume snapshot, or by an offsite job outside the Service, those copies are on that system's own rotation, this Service cannot expire them, and the 90 day figure does not apply to them. Ask privacy@oraglegpt.org for the rotation actually in force on the deployment you use.

10. Security

The measures actually implemented in this release include:

• Encrypted application state. Tenant data at rest is held in an encrypted PostgreSQL database on an encrypted volume. Tenant-owned tables additionally carry PostgreSQL FORCE ROW LEVEL SECURITY, so isolation is enforced by the database and not only by the application.
• Credential sealing. Social, AI, and integration credentials are stored in sealed envelopes, are never returned by the API, and are omitted rather than echoed as redacted placeholders.
• Transport security. HTTPS with automatic certificate management at the reverse proxy.
• Session security. HttpOnly, SameSite=Lax, Secure-on-HTTPS session cookie; absolute and idle expiry; server-side revocation.
• Strong authentication. Password plus TOTP, recovery codes, and WebAuthn passkey foundations; step-up authentication for operator diagnostics and sensitive actions.
• Authorisation. Tenant isolation on every record, RBAC and ABAC, and approval workflows for publishing.
• Trusted proxy handling. Right-to-left forwarding-chain validation so client IP attribution cannot be spoofed.
• Integrity of outbound events. Webhook deliveries are signed with HMAC-SHA256 over a timestamp and body, with replay protection, secret rotation, retry, dead-letter, and automatic disable thresholds.
• Auditability. Append-oriented audit and publication-attempt records.
• Backups. Encrypted, context-bound backup envelopes with tamper detection, verified restore, and offline master-key rotation.
• Secret hygiene. An automated secret scan runs in the release verification gate.

No system is perfectly secure. Report a suspected vulnerability to security@oraglegpt.org. Our published security posture and known limitations are in our Security page, our published threat model, and our published list of known limitations.

11. Your rights

11.1 If GDPR or UK GDPR applies to you

You have the right to access, rectify, erase, restrict, and object to processing; to data portability; to withdraw consent at any time without affecting prior processing; and to lodge a complaint with a supervisory authority. We do not carry out solely automated decision-making that produces legal or similarly significant effects.

11.2 If you are a California resident (CCPA/CPRA)

You have the right to know the categories and specific pieces of personal information collected, the sources, the business purposes, and the categories of third parties involved; to delete; to correct; to limit the use of sensitive personal information; to opt out of sale or sharing; and not to be discriminated against for exercising a right. We do not sell or share personal information, so there is no "Do Not Sell or Share My Personal Information" mechanism to operate, but you may still submit a request to confirm this. Authorised agents may submit requests with proof of authorisation.

The categories in section 4 map to the CCPA categories: identifiers, customer records, commercial information, internet or network activity, geolocation inferred from IP, professional information, and the contents of electronic messages where a customer enables inbox features.

11.3 Other jurisdictions

Residents of Virginia, Colorado, Connecticut, Utah, Texas, and other US states with comprehensive privacy laws, and residents of Brazil (LGPD), Canada (PIPEDA), and other jurisdictions, have broadly equivalent rights. We apply the same process to all of them.

11.4 How to exercise a right

Email privacy@oraglegpt.org from the address on the account. Email is the route for every right in this section: the in-product controls in this release cover only the narrower self-serve actions in Data Deletion Policy sections 3.1 and 3.2, and no screen raises a full erasure request. We will verify your identity proportionately to the sensitivity of the request, acknowledge within 72 hours, and respond within 30 days, extendable once by a further 60 days where the request is complex, with notice to you.

If your data is inside a customer's tenant (for example, you sent a DM to a brand that uses the Service), we are the processor. Contact that brand. If you contact us, we will forward your request to the relevant customer and tell you we have done so, unless doing so would itself breach a legal duty.

Deletion is documented separately and in operational detail in Data Deletion Policy.

12. Cookies and local storage

See Cookie and Local Storage Policy. In short: a strictly necessary session cookie named orbitpost_session, browser local storage used by the installable PWA and its service worker, and no advertising cookies.

13. Platform-specific commitments

To satisfy the developer terms of Meta (Facebook, Instagram, Threads), TikTok, X, LinkedIn, Google (YouTube and Google Business Profile), Pinterest, Reddit, and Mastodon instances, we commit that:

1. Platform data is used only to provide the features the connecting customer has enabled, and for no other purpose.
2. We do not sell, licence, rent, or transfer platform data, and we do not use it for advertising, ad targeting, or building profiles of platform users.
3. We do not use platform data to train machine-learning models.
4. We request the minimum scopes for the enabled features, and we drop scopes when a feature is disabled.
5. We delete stored authorisation credentials when the account is disconnected, when its account record is deleted, when a verified deauthorisation callback requires it, and when the workspace holding them is deleted at the end of its 30-day closure window. We delete broader platform data when the relevant record is deleted, on a verified deletion callback, on a verified request, or with the workspace. Revocation at a provider that sends no callback is not by itself an authenticated local deletion request. See Data Deletion Policy.
6. We publish a data deletion instructions URL and, where the platform requires it, a data deletion callback endpoint.
7. We honour platform rate limits, automation rules, and messaging policies, and we enforce them on customers through Acceptable Use Policy.
8. We keep platform data logically separated per tenant and access-controlled.
9. We flow equivalent obligations down to subprocessors.
10. We will delete platform data on a platform's instruction and confirm when it is done.

13.1 YouTube API Services

YouTube cannot be connected in this release, so we hold no YouTube data. The connector has no authoritative account-identity resolver, so the authorisation flow refuses to start and no YouTube channel can be linked to a workspace. We publish this clause anyway, and keep it accurate, so that it is already in force the moment the connector is enabled rather than written after the fact.

Where a customer does connect a YouTube channel, GPTpost uses YouTube API Services. In addition to everything above:

• By using the YouTube features of GPTpost you are agreeing to be bound by the YouTube Terms of Service, available at https://www.youtube.com/t/terms.
• Google's own handling of your information is governed by the Google Privacy Policy, available at http://www.google.com/policies/privacy.
• You can revoke GPTpost's access to your YouTube data at any time through the Google security settings page at https://myaccount.google.com/permissions. Google does not send this release a guaranteed deletion callback, so use the GPTpost self-serve or verified email route in Data Deletion Policy as well when you want a deterministic local deletion.
• The YouTube connector is upload-only. Its single operation is to upload one video or Short with the title, description, tags and privacy status the customer supplies, using the scopes listed in section 4.2. It makes no comment call, no moderation call, and no analytics or reporting call, so we do not read YouTube comments, we do not post, hide, moderate or delete them, and we store no YouTube analytics or aggregated YouTube metrics of any kind. We do not use YouTube data for advertising, we do not sell it, and we do not use it to train models.
• The only YouTube data we would hold is therefore the OAuth token for the channel, the channel and video identifiers the upload returns, and the publication attempt record that logs what we sent and what YouTube answered. A channel disconnect destroys the stored credentials and, if you choose Delete account record, the account record; it does not erase the publication attempt log, which you can delete separately, with the workspace, or by a verified deletion request.

13.2 Google user data generally

For Google Business Profile as well as YouTube, our use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. That policy is at https://developers.google.com/terms/api-services-user-data-policy.

13.3 Meta, TikTok, LinkedIn, and X

• Meta (Facebook, Instagram, Threads). We publish a data deletion instructions URL at https://oraglegpt.org/legal/data-deletion and honour the deauthorisation and deletion callbacks described there.
• TikTok. We comply with the TikTok Developer Terms and the Content Sharing Guidelines, including the creator disclosure and commercial content controls.
• LinkedIn. We use member and organization data only for the features the customer enables, under the LinkedIn API Terms.
• X. Our handling of X data is no less protective than the X Privacy Policy, and we follow the X Display Requirements wherever we render posts.

Reviewer note. Release 3.4.0-fullpower.1 ships connector definitions and capability metadata for the providers above. Live provider credentials, approved platform applications, and completed app review are operator responsibilities and are not present in this release. Fixture data must never be presented as live provider delivery. See our social platform capability matrix.

14. Children

The Service is a business product and is not directed to children. We do not knowingly collect personal information from anyone under 16 (or under 13 where that is the applicable threshold). If you believe a child's data has reached us, write to privacy@oraglegpt.org and we will delete it.

Note that public comments and DMs a customer submits to the unified inbox may originate from minors. Customers must handle that data in line with their own obligations and the relevant platform's policies.

15. Changes to this policy

We will update this page when the Service changes. Material changes are announced in-product and by email to workspace administrators at least 30 days before they take effect, unless a change is required sooner by law or by a platform. The "Last updated" date at the top always reflects the current version. Superseded versions are retained and available on request.

16. Contact

GPT LLM ORAGLE Ltd. Liability Co.
30 N Gould St, Ste N
Sheridan, WY 82801
United States

We respond as the Company. We do not identify individual personnel in correspondence about this policy.