Social Posting API Checker

Gotchas (4)

• Posting costs money. A 402, or any error body mentioning “credit”, is X telling you the developer account needs API credits — that is X’s pricing, not a seenpaid limit.
• Video cannot use the single-shot upload: it has to go through chunked INIT / APPEND / FINALIZE, then a STATUS poll while X transcodes. The simple endpoint answers “media type unrecognized”.
• The 5th image onward is dropped with no error (slice(0, 4)).
• A pre-BYOK OAuth 2.0 connection is rejected before the API call — X answers OAuth 2.0 app-only auth on /2/tweets with a 403.

Gotchas (3)

• A URL in the text is dead plain text unless the record carries richtext facets, and facet offsets must be UTF-8 BYTE ranges — one emoji before a link shifts a character-index facet off target.
• An embed is exactly one of images / video / external, never mixed, and video uses a single blob rather than an array. A video blob placed in images.image is refused: “Expected image/* got video/mp4”.
• A 4xx from the PDS means the app password is gone (reconnect); a 5xx is a blip worth retrying. Collapsing both used to disconnect healthy accounts.

Gotchas (4)

• Every request needs a LinkedIn-Version: YYYYMM header, and versions are supported for roughly 12 months. A sunset value fails with 426 NONEXISTENT_VERSION — this has already bitten once in production.
• One image must use the `media` content type. `multiImage` requires 2–20 images, so a single-image multiImage post 422s with “size of images, found 1, is out of range 2...20”.
• The created post URN comes back in the x-restli-id response header, not the body.
• The adapter filters to type === image, so a video attached to a LinkedIn post is silently not posted.

Gotchas (6)

• The publishing permission is instagram_content_publish. Meta’s own “API setup with Facebook login” guide prints instagram_content_publishing — a typo in their docs. The Permissions and Features catalog is the authority.
• A caption set on a carousel CHILD container is silently ignored. It belongs on the CAROUSEL parent.
• media_type REELS is rejected as a carousel child — child videos must be media_type VIDEO. REELS is only valid for a standalone single video.
• Carousel children are created one at a time, not in parallel: Meta rate-limits container creation, and a partial parallel failure leaves orphaned containers with no id trail.
• The numeric Graph media id is not a permalink. instagram.com/p/<media id> 404s on every post — the real /p/<shortcode> URL has to be fetched with fields=permalink afterwards.
• Container processing is polled for ~18s only, to stay inside the worker’s 25s publish timeout. A long video fails with a clear error instead of risking a duplicate post.

Gotchas (3)

• Three different shapes for one post: no image → /feed, one image → /photos with a caption, several → unpublished /photos uploads collected into attached_media on a /feed post.
• The adapter filters to type === image, so a video-only Facebook post publishes as text with the video quietly missing.
• Meta does not always return expires_in on the long-lived token exchange (observed live), so the adapter falls back to 60 days rather than storing an invalid date.

Gotchas (6)

• Nothing goes live. The video lands in the creator’s TikTok drafts (/v2/post/publish/inbox/video/init/) and somebody has to open the app and tap Post. Direct Post needs TikTok’s content-posting audit.
• The caption never reaches TikTok. The inbox init request carries only source_info, so whatever you wrote has to be retyped in the app — despite the composer offering a 2,200-character limit.
• A dead refresh token comes back as HTTP 200 with an invalid_grant body, so a status check alone is no guard. Measured against the live endpoint on 2026-08-16.
• One chunk, so 64MB is the hard ceiling; over that the post fails loudly instead of truncating.
• Exactly one video is required. Images are never looked at.
• There is no public post URL until the creator publishes it, so the account profile is surfaced as a placeholder.

Gotchas (3)

• The token from the code exchange is short-lived (~1h) and must immediately be swapped via th_exchange_token, or every connection dies within the hour.
• A failed refresh must throw, not no-op. Returning a token set with no expiry once nulled the stored expiry, and the sweep only selects rows where expires_at is not null — the account went permanently invisible and read as “active” for 8 days after expiring.
• One image, chosen with find(type === image). Videos have no code path.

Gotchas (4)

• pins:write is not enough. Pinterest classes POST /pins as writing to the board, so boards:write is also required — proven by a real 401 “Missing: ['boards:write']” on the first live pin.
• The Pin goes to whichever board the API returns first (GET /boards?page_size=1). There is no board picker.
• The caption is split: first line becomes the Pin title (capped at 100), the rest becomes the description (capped at 800).
• An image is mandatory — a Pin cannot exist without one.

Gotchas (3)

• A multipart file part with no filename is refused by Mastodon and many Fediverse servers, so the adapter derives one from the content type.
• Video and GIF uploads return 202 with url: null while the server transcodes. Attaching that id to a status too early 422s with “files that have not finished processing”, so the adapter polls GET /api/v1/media/:id (200 = done, 206 = still going) for up to 20s.
• Federated: the 500-character limit is this instance’s default, and instances are free to configure a different one. The adapter does not read the instance’s own limit.

Gotchas (3)

• The adapter hard-truncates the message at 2,000 characters rather than letting Discord reject it.
• Only type === image is attached — a video is dropped.
• The webhook URL is validated by GETting it, so a revoked webhook is caught at connect time.

Gotchas (4)

• Attaching a photo cuts the usable caption from 4,096 characters to 1,024: sendPhoto’s caption is truncated at 1,024 by the adapter. The composer’s limit table only knows about 4,096.
• The bot must be an admin of the channel, checked with getChat at connect time.
• A post URL only exists if the channel has a public username; otherwise the published post has no link.
• Telegram answers errors with HTTP 200 and ok: false, so the adapter checks the body, not the status.

Gotchas (3)

• Posts go to the PRIMARY blog only — the blog picked by find(primary) at connect time. There is no per-post blog choice.
• Neue Post Format, so the body is a content-block array: the image block is prepended, the text block follows.
• One image, chosen with find(type === image). Videos have no code path.

Gotchas (3)

• Incoming Webhooks are write-only: no message id and no permalink come back. The stored post id is synthesized and the post has no URL to link to.
• Because the endpoint is write-only there is nothing to GET, so the credential is validated only by URL shape at connect time.
• One image, chosen with find(type === image). Videos have no code path.

Gotchas (3)

• This publishes an ARTICLE, not a status: the caption’s first line becomes the post title and the rest becomes the HTML body.
• Because the image is only linked, the post depends on our media URL staying reachable — it never becomes a WordPress attachment.
• The target is user-supplied, so the request goes through the self-hosted fetch guard: the site must resolve to a public address.

Gotchas (3)

• Publishes an ARTICLE: first line of the caption becomes the title, the rest becomes HTML.
• The key must be in id:secret form with a hex secret — anything else is rejected at connect time before a request is made.
• The target is user-supplied, so the request goes through the self-hosted fetch guard: the site must resolve to a public address.

Gotchas (2)

• Publishes an ARTICLE: first line of the caption becomes the title (capped at 250 characters), the rest is markdown.
• This is the lowest-friction API of the set — a pasted key posts immediately, with no app registration or review.

Gotchas (3)

• Publishes an ARTICLE via the publishPost mutation: first line becomes the title.
• PublishPostInput.tags is typed non-null, so omitting tags fails GraphQL validation — an empty array has to be sent explicitly.
• The account is keyed by publication id, so a post always lands on the blog you connected.

Gotchas (2)

• Medium deprecated the creation of NEW integration tokens. This works if you already hold one, and a new account may simply be unable to make one.
• Publishes an ARTICLE with contentFormat: markdown and publishStatus: public — first line becomes the title.

Gotchas (4)

• A Lemmy post needs a title, so the caption’s first line becomes it (capped at 200 characters) and the rest becomes the body.
• Attaching an image turns the post into a link post pointing at the image URL — it is not embedded in the body.
• The community is resolved to an id at connect time, so every post goes to that one community.
• The instance is user-supplied, so the request goes through the self-hosted fetch guard: it must resolve to a public address.

Gotchas (4)

• No cap on attachments, but also no attachment mechanism: media is just URLs pasted at the end of the text, and whether they render is up to the reader’s client.
• A publish succeeds if at least ONE relay accepts the event; each relay is raced against an 8-second timeout, because a relay that accepts the socket and never answers would otherwise hold a worker slot forever.
• There is no canonical post URL — the adapter builds an njump.me link from the nevent id.
• Relay connections need a WebSocket implementation injected on Node 20; the global only exists from Node 22 up.

Gotchas (3)

• With a secret set, each request carries X-Seenpaid-Signature: an HMAC-SHA256 of the exact raw body, so the receiver can verify it came from us.
• “Any https URL” is not any address. The target is checked at connect time AND on every publish: private, loopback and cloud-metadata ranges are refused and redirects are not followed.
• Every media asset is forwarded, with no cap and no filtering by type.