Q:

Should I have a queue with SMS requests to picked up by a separate process or connect directly to the API?

I created an email queue where I put the requests for emails to be sent. If the SMTP server is unavailable, the requests are not lost.
When the SMTP server gets back online, the background service will pick up the requests to send the emails and process accordingly.
Question: I now have a requirement to deliver text messages with high certainty, but also to give feedback about a wrong phone number if that is possible. Should I have something like my mail queue to send text messages to my user phones or not?
I think it makes sense if we're talking about marketing messages, but what about text messages sent to users to verify their phone numbers?
What if their phone number is typed incorrectly? The phone API will tell me right away but if I put the request in the queue, I won't be able to let them know about it.
Rephrasing of the question: Should I care about the immediate feedback and loose the ability to deliver all SMS messages in case of temporary failure?

A:

Depending on the API for sending text messages, there are two possibilities for meeting those business requirements.

If there are separate API calls to verify a phone number and to send a text message, you can use a queue for the actual sending and verify the validity of the phone number just before you put the text message in the queue.
If there is only an API call to send a text message, which informs you about success/failure after the fact and where the failure codes are descriptive enough, you could send the message initially from the context of the user request. If that fails with a temporary error, add the message to a queue for later retries.

