Очередной ответ в API Mandrill не совпадает с ответом в очереди с сервера получателя.
Когда вы отправляете сообщение через Mandrill, вы сначала передаете его Mandrill, Mandrill обрабатывает его, а затем Mandrill передает его на сервер получателя. Все это происходит довольно быстро, но два этапа ретрансляции являются отдельными и раздельными. К статье, к которой вы привязались, содержится дополнительная информация об этом последнем шаге, ретрансляция на серверы получателей, нет a queued
статус для API Mandrill.
Существует ряд причин, по которым API Mandrill может отвечать queued
, включая, если вы добавили вложения или отправили кучу получателей в одном вызове API.
Не видя фактического вызова API, это сложно сказать , почему вы получаете ответ queued
. Но если вы используете пример отправки сообщений/отправки API, вам нужно удалить все необязательные параметры, которые вы на самом деле не устанавливаете. Например, образец имеет поддельные вложения, и указан субсчет. Вложение приведет к обработке вызова async. Субсчет, вероятно, не существует и приведет к сбою вызова. Поэтому, если это так, попробуйте удалить все эти необязательные параметры. Если нет, предоставьте API-запрос, который вы создаете с измененными конфиденциальными данными (ключ API, фактические адреса электронной почты).
После того, как вы отправите запрос, если вы сделаете еще один звонок, чтобы прочитать информацию об этом сообщении, он все еще говорит в очереди (может быть, попробуйте подождать минуту и посмотреть, все ли это говорит)? Когда вы первый раз отправляете запрос, я уверен, что они поставят его в очередь, но я думаю, что это довольно быстро изменилось. – mattetre