API visibility for admin‑initiated outbound emails before a reply | Community
Skip to main content
Answered

API visibility for admin‑initiated outbound emails before a reply

  • August 17, 2026
  • 5 replies
  • 154 views

When an admin sends an outbound email from Intercom, the message exists as a message object but no conversation is created until the recipient replies. Because of this, the API cannot retrieve the outbound email via the conversations API (GET /conversations/{id}) until a reply occurs.

Request: allow the API to retrieve admin‑initiated outbound emails immediately after sending, even if the recipient has not replied yet. This would enable better auditing, logging, and integration workflows for outbound communications.

Best answer by jackofalltrades

Solved this. Sharing for anyone who lands here.

POST /messages accepts create_conversation_without_contact_reply: true.

With it set, the response includes a real conversation_id immediately. That conversation is returned by GET /conversations/{id} and by POST /conversations/search on contact_ids right away, before the recipient replies. It also comes back already assigned to the from admin.

Without the flag, you only get an admin_message id and no conversation until a reply or an inbox action, which is the behavior I described above.

On the sender side, with a verified custom sending domain, the email went out as our workspace support@ address, not the admin signup email. I verified this using the raw From header.

Tested today on API version 2.16. The flag is in the OpenAPI spec but easy to miss in the docs.

5 replies

Aleksei O
Super User ✨
Forum|alt.badge.img+5
  • Super User
  • August 18, 2026

Hi ​@jackofalltrades ! Could you share what kind of workflows you have in mind for delivered outbounds? While I don’t work for Intercom, I could at least suggest some workarounds here! 


  • Author
  • New Participant
  • August 30, 2026

Basically want to be able to create new outbound emails from an email already setup on the account via API.

We can do this in the intercom UI , start a new email conversation and have it sent from our company email but this cant be done via the API.


Aleksei O
Super User ✨
Forum|alt.badge.img+5
  • Super User
  • August 31, 2026

Hi ​@jackofalltrades ! We are just discussing this during Community Office Hours with ​@Roy and ​@Nathan Sudds ! 

Have you considered using Series for this? E.g. if the first email is not delivered, send another one after x days? What exactly are you trying to accomplish here? 


Nathan Sudds
Top Expert ✨
Forum|alt.badge.img+8
  • Top Expert
  • August 31, 2026

@jackofalltrades we are trying to answer your question right now on the Fin Community Office Hours, feel free to watch the recording to learn more -- as ​@Aleksei O shared on the thread and on the Office Hours -- we’re curious about if you’ve tried to use Series here for your user case and it didn’t work or you need to it manually?  We’re finding that there is a way to do this via the API but there’s not a lot of documentation about this. 

@Roy is going to share a workaround and I’ve demoed how Claude found a way to track the conversation ID at the point of creation so you should still be able to track this.   Check out the video!


  • Author
  • New Participant
  • Answer
  • September 2, 2026

Solved this. Sharing for anyone who lands here.

POST /messages accepts create_conversation_without_contact_reply: true.

With it set, the response includes a real conversation_id immediately. That conversation is returned by GET /conversations/{id} and by POST /conversations/search on contact_ids right away, before the recipient replies. It also comes back already assigned to the from admin.

Without the flag, you only get an admin_message id and no conversation until a reply or an inbox action, which is the behavior I described above.

On the sender side, with a verified custom sending domain, the email went out as our workspace support@ address, not the admin signup email. I verified this using the raw From header.

Tested today on API version 2.16. The flag is in the OpenAPI spec but easy to miss in the docs.