I am trying to use the FUEL API to unsubscribe a mobile number from a particular keyword on a private shortcode. I would be fine with a global opt out on that private shortcode, as well.

I have tried a MO message (/sms/v1/queueMO/) with different unsubscribe keywords (STOP, UNSUBSCRIBE, QUIT, etc.) and the response is always that that keyword does not exist. I have tried using the original keyword as the verb and unsubscribe keywords (see above) as nouns but that doesn't work either (I get a text saying "Sorry, there was an error. Please try again.")

I have also tried to use message contact send (/sms/v1/messageContact/{messageId}/send) to set the subscribe and resubscribe values as FALSE but this does not seem to do the trick, either.

I am thinking that a custom import definition would do the trick but I want to avoid that as it would require the creation and maintenance of a DE outside the Mobile Connect tool and then additional API calls to update that DE and then trigger an import. Not to mention it wouldn't be near-realtime.

Does anyone know if there is an API call that can simply unsubscribe someone (a mobile number) from an SMS campaign/keyword/shortcode?

Use Case for this is allowing a user to manage their SMS campaign subscriptions from a Web Portal - User Preferences page.

Attribution to: Alex Finger

Possible Suggestion/Solution #1

To unsubscribe from ALL keywords for a certain shortcode, you can send a QueueMO call to that shortcode with the message text of "STOP".

ExactTarget has informed me that their system does not discriminate against QueueMO calls within the API and true MO texts from the physical device.

Call used:

{
    "mobileNumbers" : [
        "15555551212"
    ],
    "shortCode" : "12345",
    "messageText" : "STOP"
}

Attribution to: Alex Finger

Possible Suggestion/Solution #2

The optout can occur at the MID level using a Custom Stop. So setup a second STOP like 'STOP1' keyword in the BU you want to unsubscribe from. This will limit it to just that BU.

There is no reason that QueueMO call wouldn't work. Question would be is the ClientID/Secret you are using to trigger the call owned in the MID that holds the STOP. Because if not, then that error makes sense as the accessToken is MID Specific in context for what is matching to look for.

Attribution to: B Gaines
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/34780