Endpoint 404 Errors: Explanation and Scenarios

Endpoints will sometimes return 404 errors immediately after trying to retrieve (GET) the object following a webhook for object.created. This document aims to explain this behavior.

Note: If you receive a 404, you should consider the item deleted. Typically, this makes up 1% of all HTTP responses.

Note: Ensure you are using the correct token to retrieve an object, failure to do so will return a 404.


Endpoints: /messages & /threads

Scenario / Cause

  • Offset: When no more objects can be located, i.e., end of an offset / limit, we return a 404.
  • Draft: Creating a draft (/draft) then sending it (/send) changes the message_id, resulting in two webhooks for the same message, one returning a 404.
  • Consolidate: A message sent, then receiving a message.created webhook which returns a 404. This can happen as the messages are consolidated or providers change the ID, especially common with IMAP.
  • Provider: The message is permanently deleted on the provider. The next time you try to retrieve it, you receive a 404 as there is no message.deleted webhook.
  • RAW Message/rfc822: GET /messages with message/rfc822 (RAW) returns a 404, but without message/rfc822, it returns 200. The email is likely in a deletions folder, and the provider doesn't return the raw content of messages in the deletions folder. It is also possible that the message does not exist on the provider, in which case it will shortly be deleted on Nylas as well.

Endpoint: /files

  • Scenario / Cause: If the message objects have been moved to Deleted items / Deletions, then the attachment returns a 404. Refer to "How long do you store an uploaded file for?"

Endpoint: /events

Scenario / Cause

  • Provider: GET /events immediately after event.created results in a 404, with no correlating POST in API logs. This occurs when an event is created by the provider, synced by Nylas, and then promptly permanently deleted by the provider. These events are not created by the user via the provider, as deleted events by the user simply change the status to cancelled.
  • Unknown Events: We do not track what these events are. However, add-ons or browser plugins to mail clients, such as time-management software, can cause this behavior.

Resources

 

Updated

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.