How X (Twitter) Publishing Works with Postproxy
X's publishing model
X (formerly Twitter) uses a v2 API that requires OAuth 2.0 with PKCE for user-context authentication. Publishing a tweet is a single POST request, but media attachments require a separate multi-step upload flow through the v1.1 media endpoint — the v2 API still relies on v1.1 for media uploads. Postproxy handles this split: send your text and media URLs in one request, and the API manages the v1.1 media upload followed by the v2 tweet creation automatically.
Media uploads and format detection
X's media upload endpoint uses a chunked upload protocol for videos and GIFs over 5MB. Each chunk must be uploaded sequentially, with a finalize step at the end and optional status polling for async video processing. Images are simpler but still require a separate upload-then-attach flow. Postproxy detects the media type from your URLs, chooses the correct upload method, handles chunking for large files, and attaches the resulting media IDs to your tweet.
Common gotchas Postproxy handles for you
X has some of the strictest rate limits of any social platform — as low as 17 tweets per 24-hour window on free-tier API plans, with separate limits for media uploads. The API also has a 280-character limit for tweet text (with URLs counting toward the limit differently than plain text). Error responses from X are often vague, returning generic 403s for multiple distinct issues. Postproxy validates content length, manages rate limit windows, and translates X's error codes into actionable messages.
Threads and reply chains
Posting a thread on X requires creating each tweet sequentially, with each reply referencing the previous tweet's ID. If any tweet in the chain fails, you're left with a partial thread. Postproxy's thread support lets you send an array of tweet contents and handles the sequential posting with proper reply chaining, rolling back on failure so you don't end up with orphaned partial threads.
