A BlueSky invalid record type error usually means the API received a record that does not match the expected AT Protocol lexicon schema. The write might be close, but one field, union type, timestamp, facet, tag, or nested object is shaped incorrectly.
For scheduling teams, these errors are not just developer noise. A malformed payload can block a planned post, create duplicate retry attempts, or force a marketer to rebuild a draft at the worst possible time.
Read the official AT Protocol Lexicon spec to understand how record schemas and validation constraints are defined.
Start with the record type
A normal BlueSky post record is app.bsky.feed.post. The public lexicon defines it as a record with required text and createdAt fields. If your payload uses the wrong collection, omits required fields, or nests the post object in the wrong place, validation can fail before the post ever reaches a feed.
Inspect the app.bsky.feed.post lexicon for required fields, embeds, facets, tags, and text limits.
Common invalid record causes
- Missing required text or createdAt fields on an app.bsky.feed.post record.
- Using the wrong $type or collection for the record you are trying to create.
- Sending text as an object or array instead of a string.
- Crossing the BlueSky post limits of 300 graphemes or 3000 UTF-8 bytes.
- Building rich text facets with byte offsets that do not match the UTF-8 text.
- Sending an embed union without the expected nested shape for images, video, external links, records, or record-with-media objects.
- Adding too many tags or tags that exceed the lexicon limits.
- Using a createdAt timestamp that is missing timezone context or is not a valid datetime string.
Before publishing, run drafts through the BlueSky payload size and byte counter and check long posts before the scheduler submits a record.
Why rich text facets fail
Facets are powerful because they attach links, mentions, and hashtags to exact spans in the text. The trap is that AT Protocol facets use byte offsets, not plain visual character positions. Emoji, accented characters, and some symbols can shift byte counts and make an otherwise correct-looking link annotation invalid.
If a draft includes Markdown links or hashtags, convert them with the BlueSky Markdown facets converter before moving the post into a production queue.
Why createdAt can trigger rejection
BlueSky post records include a client-declared createdAt timestamp. If automation sends a malformed timestamp, omits timezone context, or uses an unexpected format, the record can fail validation or sort badly after it is accepted.
Use the BlueSky timezone and ISO timestamp converter when a scheduling workflow needs exact datetime formatting.
A safer diagnostic workflow
- Confirm the intended collection and $type before writing the record.
- Validate required fields and primitive types first.
- Check text length by both graphemes and UTF-8 bytes.
- Recompute facet byte offsets after every text edit.
- Validate embed unions independently before adding them to the post.
- Use a single controlled retry path instead of blind repeat writes.
Where ONYX fits
ONYX helps by turning post creation into a reviewed queue instead of a raw payload scramble. Drafts can be checked for character limits, byte size, timestamp shape, and thread structure before a scheduled post is approved for publishing.
That does not remove the need for official API validation. It reduces the chance that a malformed draft enters the active queue and fails during a live campaign window.
Schedule reviewed BlueSky posts with ONYX when you want draft checks and approvals before publish time.
Review BlueSky's post creation guide for practical payload examples and rich text guidance.