CODEWITHSUNDEEP
c#twiliotwilio-api
VaultBoy14
VaultBoy14

Reputation: 251

Is there a way in Twilio to write back that we failed to process an inbound text?

I have an api that handles inbound text messages from Twilio. Occassionally we have network outtages or other issues that cause the API receive the text, but be unable to save to the database.

We want to build out some redundancy so we can reprocess Text that failed after a short wait. We can't rely on just sending HTTP error codes to twilio because we get alot of false positives int the Twilio error logs due to slowness in replying or the message can blow up far down the food chain.

I noticed in Twilio when we do reply with HTTP error codes we can manually resend the Text from the web api.

Is there a way to make an API call to Twilio to set some failed state, so that some maintenance operation can check Twilio for failed messages and resubmit?

Currently using the latest Twilio Nuget package v5.2.0

Upvotes: 0

Views: 328

Answers (2)

AxelTheGerman
AxelTheGerman

Reputation: 1154

As mentioned in the other answer, Twilio (nor most other services) will help you with this - you should use some kind of background processing system on your end.

  1. Message comes in from Twilio
  2. Queue a background job
  3. Reply with 200 or 201

Now you have full control over handling errors on your end.

Also useful though are Twilio's settings for timeouts and retry policies. I wanted to send any 5xx errors to my fallback service which can be done by adding #rp=ct,rt,5xx or similar to your callback URL.

See https://www.twilio.com/docs/usage/webhooks/webhooks-connection-overrides for full options.

Upvotes: 0

philnash
philnash

Reputation: 73075

Twilio developer evangelist here.

The best way to deal with this is to use a fallback URL for your number.

When you return an error code to Twilio because your service is down or times out then Twilio will make a second request to a fallback URL that you can set (see picture).

The fallback URL is set underneath your primary webhook handler

We recommend you make that URL point to a different application, so that issues with your primary application doesn't also affect your fallback. Then, with this application you could store all the messages that failed to be processed by your primary handler and process them at a later time.

Let me know if that helps at all.

Upvotes: 1

Related Questions