Singe Send API response "id"


We are using the 'Single Send API' to send emails from our application.

This works fine. When an email is sent we get a json response back that looks like the following:

    "sendResult": "SENT",
    "id": "5419d8e3-ce45-4e79-855c-14c97e1b8fc5",
    "eventId": {
        "id": "5419d8e3-ce45-4e79-855c-14c97e1b8fc5",
        "created": 1545231905349
    "correlationId": null,
    "message": null

Our application stores the id that we got back from the response.

Later on we do a call to the API: /email/public/v1/events?eventType=BOUNCE to see if the mail was BOUNCED or not.

But, sometimes an email gets queued instead of being sent directly. When that happens, then we get the following response back from the Single Send API:

	"sendResult": "QUEUED",
	"id": "00000000-0000-0000-0000-000000000000",
	"message": "Message queued for processing"

The problem we have here is the Id. It is always 00000000-0000-0000-0000-000000000000 for every email that gets queued. So there is no way for us to track the sent email because we get no id back.

I'm not sure if that is a bug, or is this by design?

Or, do you have any alternatives for us that we can use?

Kind regards,



Welcome, @GCDavid.

I can confirm that this is expected behavior at this time. The id in the eventId object is generated when an email is sent; it does not exist yet when it is QUEUED, so 00000000-0000-0000-0000-000000000000 is returned.

While this behavior is relatively rare, I certainly see how it disrupts your normal process. Unfortunately, I don't know of any alternative solutions right now.

I'll notify the product team which owns the Single Send API of your use case. If they don't have an immediate workaround, I'll advocate for adjusting our process to return id values even when a message is QUEUED.


A work around I can think of right now is that you when you get "sendResult" as QUEUED, you can call to the API: /email/public/v1/events?recipient=X later to check the status of the event and update to your system.
You will also know this way, if email bounces.


Love that, @dhirajpandey!


Thanks for the suggested workaround! I guess we have no other option than to do something like that.

But, I really hope that in the future this "issue" will be picked up by the dev team so that an "Id" will always be returned, even when it gets queued first.