Product: Posting API Operator: Keelinnovation LLC (VariantPost is a DBA of Keelinnovation LLC) Effective date: 31 August 2026 Last updated: 31 August 2026
This policy applies to the Posting API service (the “Service”): a multi-tenant publishing API that other applications (“Customers”) call so their end users (“End Users”) can connect social accounts and publish content. We are not a consumer social network. We act as a processor for Customer apps: we store OAuth tokens and post metadata so we can publish on the End User’s behalf at the Customer’s request.
1. Who we are
Posting API is operated by Keelinnovation LLC (VariantPost is a DBA of Keelinnovation LLC).
We provide infrastructure. The Customer’s product is the controller of End User relationships for that Customer’s app. We process End User data to perform the publish job the Customer (and the End User, via OAuth consent) asked us to perform.
If you are an End User of a Customer app, that Customer’s privacy policy also applies. This policy covers our processing as the posting pipe.
2. What the Service does
Customers send API requests (create media, create posts, connect accounts). End Users complete a white-label OAuth Connect flow for a network. We vault tokens, transcode media when needed, and deliver posts to the network the End User authorized.
We do not sell a public social feed. We do not return tokens to Customers.
3. Networks we connect to
v1 networks we may process tokens and content for:
- Instagram (Instagram Login / Professional accounts)
- Facebook Pages
- Threads
- LinkedIn (personal member posts)
- X
- YouTube
- TikTok (draft / inbox upload)
- Bluesky
- Mastodon (per-instance)
- Telegram (bots posting to channels/groups the bot can post to)
We only access a network after the End User grants OAuth (or equivalent) permission on that network’s consent screen.
4. Information we collect
4.1 From Customers (tenants)
- Account and billing contact details
- API keys (shown once; stored as SHA-256 hashes)
- Webhook URLs and webhook signing secrets
- Configuration and usage/metering records
4.2 From End Users, via Customer apps and OAuth
- Customer-supplied
end_user_id(opaque to us; we do not ask for the End User’s name or email unless a network returns it as profile data) - OAuth access and refresh tokens, granted scopes, token expiry
- Network user / page / professional account identifiers (
remote_account_id, app-scoped IDs) - Profile identifiers the network returns in order to publish (for example Instagram user id, Facebook Page id, Threads user id, LinkedIn person URN, X user id, YouTube channel id, TikTok open_id)
- Media the Customer or End User uploads for publishing (original blobs and renditions we generate)
- Captions, alt text, and other post fields the Customer submits
- Delivery logs: timestamps, job/post/variant ids, network, success/failure codes, remote post ids and URLs
- Connect session metadata (success/cancel URLs, timestamps)
4.3 Automatically
- IP address, user agent, and request ids on Connect, OAuth callbacks, and API calls (security, abuse, debugging)
- Webhook delivery attempts to Customer endpoints
We do not scrape social graphs. We do not use End User content to train general-purpose AI models.
5. How we use information
- Authenticate Customers (
Authorization: Bearer sk_live_…/sk_test_…) - Complete OAuth, refresh tokens, and keep Connections in
active/needs_reconnect/revoked/expiredstate - Transcode and store media long enough to publish (and as retained by the Customer’s plan)
- Publish, schedule, cancel, and retry deliveries
- Send webhooks to the Customer (
delivery.succeeded,connection.disconnected, etc.) - Meter usage (successful deliveries, transcode seconds, stored bytes)
- Prevent abuse, debug failures, comply with law and network platform terms
- Honour deletion and deauthorize callbacks from Meta and equivalent requests from other networks or End Users
We use network APIs only to provide or improve the publishing functionality the End User consented to.
6. Google / YouTube user data
When an End User connects YouTube, we request only:
https://www.googleapis.com/auth/youtube.upload— upload videos to the authorized channelhttps://www.googleapis.com/auth/youtube.readonly— read channel/video status needed to confirm uploadshttps://www.googleapis.com/auth/yt-analytics.readonly— read real per-video Analytics API metrics (views, watch time) for the Customer’s App/extension; existing connections must reconnect to grant this scope
We access, store, and use YouTube / Google user data solely to upload on the End User’s behalf, poll publish status, display connection state, and surface real Data/Analytics API stats to the Customer. We do not use Google user data for advertising, credit decisions, or unrelated profiling. We do not sell Google user data. We do not allow independent use of Google user data by other parties except (a) the Customer that initiated the Connect, as needed to show delivery status, and (b) Google/YouTube as the platform.
End Users can revoke Google access at any time at https://security.google.com/settings/security/permissions When Google reports the token as revoked or refresh fails, we delete stored YouTube tokens and associated Google/YouTube profile identifiers for that Connection and mark the Connection needs_reconnect or revoked.
This use is intended to comply with the Google API Services User Data Policy, including Limited Use, and the YouTube API Services Developer Policies.
7. Meta (Instagram, Facebook Pages, Threads)
We use Instagram API with Instagram Login, Facebook Pages APIs, and the Threads API as a Tech Provider: we process business/creator assets owned by other businesses because Customers ask us to publish for their End Users.
Meta permissions we request (v1) are limited to publishing and the listing of destinations:
- Instagram:
instagram_business_basic,instagram_business_content_publish - Pages:
pages_show_list,pages_read_engagement,pages_manage_posts,publish_video - Threads:
threads_basic,threads_content_publish
We do not request messaging or Human Agent for v1.
8. Legal bases (where GDPR / UK GDPR / similar apply)
- Contract — processing necessary to provide the Service to the Customer and to complete the End User’s publish request
- Legitimate interests — security, fraud/abuse prevention, metering, limited logs
- Consent — OAuth grants on each network; End Users can refuse or revoke
- Legal obligation — responding to valid deletion, preservation, or law-enforcement requests
9. Sharing
We share data with:
- The Customer that owns the tenant (delivery status, remote ids, errors — never raw tokens)
- Network platforms listed in §3, to authenticate and publish
- Infrastructure processors we use to run the Service (hosting, object storage, queues, error tracking), under contract, only to operate the pipe
- Authorities when required by law
We do not sell personal information. We do not share End User content with data brokers.
10. Storage, security, retention
- Tokens are stored encrypted at rest; API keys are stored as SHA-256 hashes
- Access is limited to systems that perform OAuth, refresh, and publish
- Media lives in object storage until deleted per this policy or the Customer’s deletion request
- Delivery logs (job/post ids, network, status, remote id) may be retained as needed for abuse investigation, dispute, and billing, then PII is dropped (tokens already gone; profile ids and media URLs redacted). Remaining operational counters are not tied to a person.
Default targets (we may shorten; we will not silently extend without an update to this policy):
| Data | After disconnect / deletion request |
|---|---|
| OAuth tokens, refresh tokens | Deleted immediately (async job; typically minutes) |
| Connection row + profile ids | Deleted or irreversibly anonymized |
| Media uploaded for that End User in that tenant | Deleted (original + renditions) |
| Delivery logs | Retained up to 90 days for abuse/billing, then PII stripped; residual logs without identifiers may remain |
Sandbox (sk_test_) data is isolated from live network APIs and may be wiped on a shorter cycle.
11. How to request deletion
You can have us delete tokens and stored profile/media data in any of these ways. Say this out loud in the App Review screencast.
A. In-product (End User via Customer)
The Customer calls DELETE /v1/connections/:id (revokes remote token where the network supports it, wipes our tokens) or POST /v1/end-users/{end_user_id}/delete (all connections, tokens, and media for that End User in that tenant).
B. Email
Email [email protected] from a contact we can reasonably match to the tenant or to a network user id. Include the network, the account handle if known, and the Customer app name. We will complete deletion or explain a lawful delay.
C. Meta — Apps and Websites → Send Request
Facebook / Instagram / Threads users can request deletion without emailing us:
- Open https://www.facebook.com/settings?tab=applications (Settings & Privacy → Settings → Apps and Websites)
- Remove our app
- Open View Removed Apps and Websites
- Click View next to the app
- Click Send Request
Meta then POSTs a signed request to https://api.variantpost.com/legal/meta/data-deletion. We verify the signature (Meta app secret and Instagram App Secret), enqueue deletion of tokens, connections, and media we hold for that user across tenants, and immediately return JSON:
{"url":"https://api.variantpost.com/legal/meta/data-deletion/status/<code>","confirmation_code":"<code>"}
The status page (pending | complete | failed) is public, human-readable, and requires no login.
If a user only deauthorizes (removes the app without Send Request), Meta POSTs https://api.variantpost.com/legal/meta/deauthorize. We mark matching connections revoked, wipe tokens, and emit connection.disconnected with reason=remote_deauthorize. We do not wait for the user.
D. Other networks
Revoke the app in that network’s account settings (Google permissions page in §6; equivalent X / LinkedIn / TikTok / etc. authorized-apps screens). We drop tokens when refresh fails or when the Customer disconnects.
E. Export
The Customer may call GET /v1/end-users/{end_user_id}/export for a machine-readable copy of connection and post metadata we hold for that End User in that tenant (tokens are never exported).
12. Children
The Service is for Customer businesses and creators. We do not knowingly collect data from children under 16 (or a higher age required in the End User’s country). If we learn we have, we delete it.
13. International transfers
Infrastructure may process data in the United States and other countries where our processors operate. Where required, we use appropriate transfer mechanisms (for example Standard Contractual Clauses) with processors.
14. Your rights
Depending on where you live, you may have rights to access, correct, delete, restrict, object, port, or withdraw consent. End Users should usually start with the Customer app; we will assist the Customer and will also honour §11 requests made to us directly. You may complain to a supervisory authority.
California / similar: we do not sell or share personal information as those statutes define “sell” / “share.” We do not use sensitive personal information to infer characteristics.
15. Changes
Material changes will be posted here with a new “Last updated” date. Continued use of the Service after the effective date constitutes notice to Customers; Customers are responsible for notifying their End Users when their own policies require it.
16. Contact
- Privacy:
[email protected] - Operator: Keelinnovation LLC (VariantPost is a DBA of Keelinnovation LLC)
- Data deletion status (Meta):
https://api.variantpost.com/legal/meta/data-deletion/status/<confirmation_code> - Terms:
https://variantpost.com/legal/terms
If a Data Protection Officer is required (for example EU establishment), that contact will be added here before we offer the Service to EU Customers as a documented establishment. Until then, use [email protected].