[yasser-aboelgheit-intercom]

Why?

The Preview translations description doesn't say which parts carry the field, so readers may expect it on contact replies too. It also doesn't mention that translations and body can disagree, which looks like a bug if you don't know why.

How?

Adds two sentences to the shared description on conversation parts, ticket parts and ticket replies: the field is null or left out on contact parts, and for parts created with a plain-text body the two can differ because translations is built from the part's content blocks.

_{Generated with Claude Code}

[yasser-aboelgheit-intercom]

Thanks for this. I checked it with the spec comparator, ref checks, and fern check (0 errors, no new warnings), and checked each claim against how the API behaves.

A few questions:

1. "Only present on parts authored by an admin or bot" — Contact parts never get translations, so the gate is right. But when you retrieve a conversation, contact parts come back with "translations": null rather than without the key. The key is left out only in search results, ticket part lists and ticket replies. Could this say "null or omitted on parts from a contact"? Admin parts can also be null, for example when there are no locales or the part is a rating request.
2. Can briefly differ — Confirmed. Translations are rendered on every request, while body can come from the stored copy. No change needed.

Holding approval for the wording in item 1.

~ Automated via Claude

[yasser-aboelgheit-intercom]

Thanks for the follow-up. I re-ran the spec comparator, ref checks and fern check (0 errors, same warnings as main), and rechecked the new sentence against how the API behaves.

Earlier item 1 (contact parts) is resolved. "Can be null or omitted, and always is on parts from a contact" matches the API: contact parts never get translations, conversation retrieve returns them as null, and search results, ticket part lists and ticket replies leave the key out. Item 2 was already confirmed. Nothing is wrong with the new wording, and nothing is still open.

Not approving only because this is my own PR.

~ Automated via Claude

[cathalging]

💬 Translations: one claim I couldn't confirm

The rest checks out:

• translations is null or left out on parts from a contact.
• It's sent as null on retrieve and left out elsewhere.
• Only descriptions change, so there's no SDK impact.

Question: where does the "briefly differ" come from?

L36431-36432, L45533-45534 and L45732-45733 say:

The translations are rendered on every request while body can come from a cached copy, so the two can briefly differ.

I couldn't find a cache behind body on the REST endpoints. Retrieving a conversation loads its parts directly and renders body and translations from the same record in the same request. The one difference I found isn't brief. For parts created with a plain-text body, body comes from that stored text while translations is rendered from the part's content blocks, so the two can differ for as long as the part exists.

Could you point to the cache this refers to? If there isn't one, I'd suggest describing the lasting difference instead, and applying the same change to the companion reference.

~ Automated via Claude

[yasser-aboelgheit-intercom]

Thanks, you're right: there's no cache behind body on the REST endpoints. I've replaced the sentence in all three places with the lasting difference: for parts created with a plain-text body, body returns that text while the translations are built from the part's content blocks, so the two can differ. The same change is going into the companion reference.

~ Automated via Claude