Data Deletion Policy and Deletion Callback Contract

Public data deletion instructions URL: https://oraglegpt.org/legal/data-deletion

This is the canonical, server-rendered URL to register with Meta, TikTok, LinkedIn, Google, and any other platform that requires a data deletion instructions URL. It returns real HTML at HTTP 200 with no login, no redirect, and no URL fragment.

The Service is operated by GPT LLM ORAGLE Ltd. Liability Co., a Wyoming close limited liability company, registered office 30 N Gould St, Ste N, Sheridan, WY 82801, United States. All deletion requests are handled by the Company through privacy@oraglegpt.org. We do not name individual personnel.

1. Why this page exists

Meta (Facebook, Instagram, Threads), TikTok, X, LinkedIn, Google (YouTube and Google Business Profile), Pinterest, Reddit, and Mastodon instances all require an application that handles their user data to publish a reachable, plain language data deletion instructions URL before app review can pass. Meta additionally requires a machine-callable data deletion callback endpoint and a deauthorize callback.

This page is that published URL, and it is also the engineering contract for the endpoints.

2. What can be deleted

Two things this table does not claim, so that nobody assumes them:

• Workspace knowledge base content is not deleted by an individual's request. Documents a customer uploads to a workspace knowledge base, and the chunks and embeddings derived from them, belong to that customer as controller. They carry no author and no platform identifier, so we have no way to attribute one to an individual, and deleting them on one person's request would delete another controller's data. Ask the workspace owner to delete the source document, or ask us at privacy@oraglegpt.org and we will pass the request to them.
• Records you created inside someone else's workspace stay with that workspace. Drafts, campaigns, schedules, and published posts are the workspace's records. Section 3.6 explains the route for those.

3. User-facing deletion flow (exact steps)

3.1 Disconnect one social account (self-serve, immediate)

1. Sign in at https://app.oraglegpt.org/. The application is served from the app. host; https://oraglegpt.org/ is the marketing site and links to it.
2. Go to Connections -> Connected Accounts (integrations/accounts).
3. Select the account.
4. Choose Disconnect account to keep its non-secret account record, or Delete account record to erase that record as well.
5. For Delete account record, type DELETE to confirm.

On confirmation the Service:

• first marks the account disconnecting, which blocks health checks, token refreshes, new publications, and queued publications from using it;
• calls the provider's token revocation endpoint, best effort, for the six connectors that carry one: TikTok, X, YouTube, Snapchat, Reddit, and Mastodon (Mastodon at your own instance's /oauth/revoke). Every other connector, Google Business Profile, LinkedIn and Pinterest included, carries no revocation endpoint in this release, so no revocation call is made for it. Where a call is made the provider may still fail or time out, and where a confidential client has no configured secret we record a failure rather than send an unauthenticated request;
• overwrites and deletes every local credential row for the account, including stale duplicate rows, and redacts credential copies from the event relay;
• leaves the account disconnected when you chose Disconnect account;
• additionally erases and deletes the account record when you chose Delete account record;
• does not automatically delete separate cached analytics, inbox messages, comments, DMs, or other provider-derived history. Delete those records in their own product area, or use the verified request in section 3.5 for broader erasure;
• leaves already-published posts in place on the platform. Delete those on the platform, or use Publishing -> Post History where the provider supports deletion through the API.

3.2 Delete specific content, messages, or contacts (self-serve, immediate)

Use the delete action on the record in Publishing, Inbox & CRM, or Media & Brand. Deletion is immediate in the live store. Backup and export files the Service writes for itself are deleted 90 days after they are written, by a scheduled sweep, so a deleted record is gone from them within 90 days. Backups taken outside the Service - a hosting provider's snapshot, a volume backup, an offsite job - are on that system's rotation and are not on this timetable; section 6 says what that means.

3.3 Close a whole workspace (with a 30-day export window)

Closing a workspace is self-serve, and it is the flow the Refund and Cancellation Policy section 3 and the Terms of Service section 17.4 describe.

Both the close and the reopen require a signed-in workspace owner or administrator and a step-up authentication challenge, because a closure starts an irreversible clock.

What survives the deletion, and why. One dated row per closed workspace is kept, carrying the closure and deletion timestamps and the number of records removed, and nothing that names you, your workspace or any person in it. It is the evidence that the deletion happened, in the same way the confirmation code in section 5 is. Billing and tax records are kept for as long as the law requires, as section 6 says. The append-only audit trail records that the deletion happened, without the deleted content, for the reason in section 6.

What deletion does not reach. Content already published to a social platform stays on that platform. Backup and export files the Service wrote for itself are deleted on their own 90-day schedule, per section 3.2.

You can still ask for a workspace to be erased by the verified request in section 3.5 instead, and sections 3.1 and 3.2 remain available for a single connected account or an individual record.

3.4 Delete your user account (with a grace period)

Deletion of your own account holder record is requested through POST /api/v1/privacy/deletion-requests, and cancelled through POST /api/v1/privacy/deletion-requests/{code}/cancel. Both require a signed-in session; raising the request additionally requires a step-up authentication challenge.

This is an API route, not a button. The Settings -> Privacy screen in this release shows what provider data is held and links to the connected accounts screen, but it cannot raise the step-up challenge the request needs, so it does not offer a Delete my account control. If you would rather not call the API, use the verified email request in section 3.5 and we will raise it for you.

Grace period: 30 days. During it the request can be cancelled by the person who raised it and nothing has been erased. What the erasure then covers is listed in section 4. The figure matches the retention line for account and workspace records in Privacy Policy section 9 - "for the life of the account, then 30 days" - and it is the figure the software enforces.

Deleting your user account does not delete the workspace: see section 3.3. If you are the sole owner of a workspace, transfer ownership first, or close the workspace itself under section 3.3.

3.5 Request deletion by email (no account required)

Email privacy@oraglegpt.org with the subject line "Data deletion request" and include:

• the email address, social handle, or provider account ID the request relates to;
• which platform the data came from, if you are a platform end user;
• what you want deleted (everything, or a specific item);
• if you are an authorised agent, evidence of authorisation.

Then:

How those replies reach you. Every step in that table is a reply written and sent by a person from the privacy@oraglegpt.org mailbox. The Service itself sends no email: it contains no mail client and no notification-delivery route, so none of these acknowledgements, confirmations, or reason letters is generated automatically, and none is delivered in the product. If you have not heard from us inside the stated window, write to the same address again and say so; there is no automated system to have swallowed it.

There is no charge. We do not require you to create an account to make a request.

3.6 If your data is inside a customer's workspace

If you interacted with a brand that uses the Service (you commented on their post, or sent them a DM), that brand is the controller and we are the processor. Contact the brand first. If you contact us, we will forward your request to the relevant customer within 5 business days and tell you we have done so, unless a legal duty prevents it.

3.7 Deleting your data at the platform instead

You can also revoke the Service's access directly on each platform. Provider revocation stops the provider from accepting the affected token, but not every provider sends us a signed deletion or deauthorisation callback. Section 4 explains the exact local effect. Use section 3.1 or 3.5 as well when you want us to erase local data.

4. What we do when access is revoked at the platform

A provider-side revocation is not always a verified request to erase local data, and providers give applications different signals:

• Verified deletion callback. A supported callback whose provider signature verifies queues the broader platform-user erasure described in section 5 and creates a confirmation code and deletion receipt.
• Verified Meta deauthorisation callback. We destroy the affected stored credentials and mark the connection revoked. Meta deauthorisation is not by itself a full data deletion request, so separately ingested content remains.
• Token refresh or API failure. A provider rejection can mark a connection as requiring reconnection or fail the attempted operation, but it does not authenticate a deletion request. It does not automatically erase stored content or account metadata.

For a deterministic local result, use Disconnect account or Delete account record in section 3.1. To erase provider-derived history as well, delete those records separately, or make a verified request under section 3.5. This avoids treating an outage, expired token, or transient refresh failure as authority to erase a customer's records.

5. Provider deletion-callback endpoint contract

5.1 Endpoint family

All provider-initiated deletion traffic terminates on one route family, on the application host app.oraglegpt.org:

POST https://app.oraglegpt.org/api/v1/platform/deletion/{provider}
POST https://app.oraglegpt.org/api/v1/platform/deauthorize/{provider}
GET  https://app.oraglegpt.org/api/v1/platform/deletion/status/{confirmation_code}
GET  https://app.oraglegpt.org/privacy/deletion-status/{confirmation_code}

Register these URLs on app.oraglegpt.org, not on the apex. The apex oraglegpt.org serves the marketing site and the published legal pages only; it runs no API, so every path above returns HTTP 404 there. The application host is the only host that answers them.

{provider} is the connector registry identifier, and only three of them answer these routes today. A reviewer who tests any other identifier receives HTTP 404 with This provider publishes no deletion callback contract. That is the correct answer, not a fault: the provider sends this Service no signed callback, so there is nothing for the endpoint to verify, and section 5.3 sets out the deletion route that does cover it.

A live identifier additionally needs that deployment to hold the Meta app secret for the app it belongs to. Where the secret is absent the route answers 409 provider_not_configured, naming the environment variable to set, rather than accepting a callback it cannot verify. It never answers 200 for work it did not enqueue.

These routes are unauthenticated by session and authenticated by provider signature. They must be:

• reachable over HTTPS on the public hostname with a publicly trusted certificate;
• excluded from any IP allowlist, basic auth, or WAF challenge that would block a provider's servers;
• excluded from CSRF protection, because there is no browser session;
• rate limited per source, with signature verification before any expensive work;
• idempotent, keyed on the provider identifier plus the provider's user identifier plus the confirmation code.

5.2 Meta: Facebook, Instagram, Threads

Meta calls the Data Deletion Request Callback URL and the Deauthorize Callback URL configured in the app dashboard.

Request. POST, Content-Type: application/x-www-form-urlencoded, one field:

signed_request=<base64url-signature>.<base64url-payload>

Verification, in this order:

1. Split on the single .. Reject if there is not exactly one.
2. Base64url-decode the payload; parse as JSON.
3. Require algorithm == "HMAC-SHA256". Reject anything else.
4. Recompute HMAC-SHA256(app_secret, raw_payload_segment) and compare to the base64url-decoded signature using a constant-time comparison.
5. Reject if issued_at is more than 300 seconds old.
6. Read user_id (the app-scoped user ID) from the payload.

Action. Enqueue an idempotent deletion job for every tenant that holds data for that app-scoped user ID: tokens, connection, profile cache, ingested inbox items and DMs, comments, and analytics rows attributable to that user.

Response. HTTP 200 with Content-Type: application/json and exactly:

{
  "url": "https://app.oraglegpt.org/privacy/deletion-status/{confirmation_code}",
  "confirmation_code": "{confirmation_code}"
}

That is the exact url the Service returns: the human-readable status page on the application host. The JSON form of the same record is served at https://app.oraglegpt.org/api/v1/platform/deletion/status/{confirmation_code} (section 5.4). Both resolve; neither exists on the apex.

The url must be publicly reachable without authentication and must render a human-readable status. The confirmation_code must be an unguessable, non-sequential identifier (at least 128 bits of entropy, base32 or hex encoded).

Deauthorize callback. Identical signed_request verification. Action: revoke and delete tokens and mark the connection revoked. Respond 200 with an empty body. Deauthorization is not by itself a full data deletion request unless the tenant policy says so, but tokens are always destroyed.

Failure handling. On a signature failure the Service responds 401 with a single detail-free invalid_signed_request code, identical for every failure mode, so the response cannot be used as an oracle. On an internal failure it responds 500 so Meta retries. It never responds 200 for work that was not enqueued.

5.3 Other providers

For every provider without a callback, the published URL plus the self-serve flow in section 3 is the compliant path, and the operator must be able to demonstrate it to a reviewer.

5.4 Status endpoint

GET https://app.oraglegpt.org/privacy/deletion-status/{confirmation_code}
GET https://app.oraglegpt.org/api/v1/platform/deletion/status/{confirmation_code}

• No authentication.
• Accept: text/html returns a human-readable page. Accept: application/json returns:

{
  "confirmation_code": "…",
  "status": "received | in_progress | completed | not_found",
  "received_at": "2026-08-04T00:00:00Z",
  "completed_at": "2026-08-04T00:03:11Z",
  "provider": "facebook"
}

• It must never reveal which tenants held the data, the platform user's handle, or any content. Status only.
• An unknown code returns status: "not_found" with HTTP 404 and no other detail, so the endpoint cannot be used to enumerate users.
• Deletion receipts, holding only the confirmation code, provider, timestamps, and outcome, are retained for 24 months as evidence of compliance. They contain no platform user content.

5.5 Execution guarantees

6. What we retain after deletion, and why

Already-published posts on a platform are controlled by that platform and by the account holder. Deleting data here does not delete a live post. Delete it on the platform, or through Publishing -> Post History where the provider's API supports deletion.

7. Verification and anti-abuse

We verify requests proportionately. For a signed-in user, re-authentication and a step-up challenge are enough. For an email request we match against data we already hold and may ask for one additional corroborating detail. We will not ask for a government identity document unless the risk of wrongful deletion demands it, and we delete any verification material within 30 days of closing the request. Authorised agents must evidence their authority.

We refuse manifestly unfounded or excessive repeat requests, in writing and with reasons, and we tell you how to complain.

8. Related pages

9. Scope and current implementation status

We publish this so that customers, data subjects, and platform reviewers can see exactly which deletion routes are live today and which depend on a platform integration being approved. We would rather state the boundary than let anyone assume more than we deliver.

9.1 Live today

9.2 Dependent on platform app approval

The machine-callable endpoints specified in section 5 are the contract we implement and register per platform, as that platform's app review is completed. A callback URL is only meaningful once the platform application it belongs to is approved and configured, so these are enabled alongside each approval rather than in advance.

This does not reduce anyone's deletion rights. Every provider listed in section 5.3 is covered today by the published instructions URL, the self-serve controls, and the verified email route. Those are the explicit paths for a provider that does not send this Service a signed deletion callback.

9.3 Reachability commitments

The deletion instructions URL and any registered callback endpoint are, and will remain:

• served over HTTPS with a publicly trusted certificate, on oraglegpt.org for the published deletion instructions page and on app.oraglegpt.org for every callback and status endpoint in section 5;
• free of basic auth, IP allowlisting, bot challenges, and login walls;
• returning real HTML or a real response body at HTTP 200, not a redirect to a fragment route;
• reachable from any source address, because reviewers test from unpredictable ones.

The apex oraglegpt.org is served through a CDN and the application host app.oraglegpt.org is served directly. The callback and status endpoints are on the directly served host, so no CDN challenge can sit in front of a provider's call.

9.4 Questions

If you are a platform reviewer and need a specific endpoint, a test account, or written confirmation of any commitment on this page, write to privacy@oraglegpt.org and we will respond within 5 business days.