SMS Gateway on own Instance of Commcare-Cloud


I am trying to setup an SMS Gateway on my own instance of Commcare. I have added a gateway via the Admin->SMS Gateway & Billing page, but when I try and send an SMS (via the Projects->Messaging->Broadcasts->Compose SMS Message, I get an error as shown in the figure below.


Do I need to setup anything else for the gateway to work? In the monolith config, I can see two parameters:

Do I need to change these? Is there anyway I can debug these errors?

1 Like

Have you created your custom backend in code? There's no real common format for how an SMS gateway communicates, so each new service requires an SMS Backend to be created in code which uses the API of your gateway. Once that's created you can wire it up through the Admin UI as you've done here.


Thanks Clayton - I am trying to use the Grapevine Backend for which there appears to already be a pre-existing backend, but when I try and use it, I get the error described above.

I have tried the HTTP Backend too, but I don't believe the HTTP URLs are being called. Are there any logs I can look at?

When looking at the Message Error Logs, all I see is the error:

Error - Internal Server Error

as shown in

I have modified SMS_QUEUE_ENABLED setting to True and re-run the cchq update-config. Would this be sufficient to enable the SMS Queue?

Hi Clayton and Dimagi Team,

Ok! I found the problem by looking at the django log and analysing the code - The shipped Grapevine Backend has a hard-coded URL which is different to the one we have been provided by Grapevine.

So now I am wondering - Would it be best to create and maintain a separate backend with the different URL -or- Do you think it would be possible to push/request a change exposing the URL as a Grapevine setting?

The hardcoded url is on line 108 of corehq/messaging/smsbackends/grapevine/
url = ''
Our url is:
url = ''

Also - Is there any advice on maintaining a different smsbackend when using Commcare-Cloud? I foresee a problem of redeploying causing the custom smsbackend to have to be redeployed separately once again.

My sense is that the best change is creating the URL as a setting of the grapevine gateway model with a migration for any existing models to set the URL to the one which is currently set, since that could go back into the core config without needing to be a separate fork.

Thanks Clayton,

Agreed that sounds like a great approach - I will see whether I can make the additions and create a Pull Request for the changes.

Thanks again