Update `alert_contact` docs to reflect unsupported SMS type

[NoelLH]

I tried to add an sms contact today and got

Error: Got error from UptimeRobot: {"message":"type is invalid.","parameter_name":"type","passed_value":"1","type":"invalid_parameter"}

Looking at the API docs, it looks like the guidance here should probably be updated?

[wolfaba]

Is it really so complex to support pro-sms (or just "sms"?) with ID 8? I thought it would be easy just adding another mapping

	"pro-sms":        8,

into

var alertContactType = map[string]int{
	"sms":        1,
	"email":      2,
	"twitter-dm": 3,
	"boxcar":     4,
	"webhook":    5,
	"pushbullet": 6,
	"zapier":     7,
	"pushover":   9,
	"hipchat":    10,
	"slack":      11,
	"hangouts":	  21,
}

[wolfaba]

Hey, the page UptimeRobot API tells lies about unsupported SMS. Adding SMS works perfect, I have tested it just now:

$ curl -X POST -H "Cache-Control: no-cache" -H "Content-Type: application/x-www-form-urlencoded" -d 'api_key=API-KEY&format=json&type=8&friendly_name=ContactName&value=phonenumber' "https://api.uptimerobot.com/v2/newAlertContact"
{"stat":"ok","alertcontact":{"id":3151556}}

I have received instantly SMS with verification code and then I have entered the code in UI during activating SMS contact.

[NoelLH]

Oh nice, thanks @wolfaba! Is anything on the UptimeRobot side that explains that type from an API perspective or is it totally undocumented?

Does the API return straight away when you do this, when the Contact is unverified, or wait for that step before responding? I guess if it's the former there might be the option of doing a GET so that this provider waits for verification for a bit, depending on how the also-seemingly-undocumented status property works.

[wolfaba]

@NoelLH I don't really understand, why they write in docs that SMS is unsupported. Maybe they don't want to document is as supported because of required verification. The contact is created as inactive so user has to activate it manually. Maybe you cannot configure the contact in TF and use it at the same time - I cannot verify this. Maybe you have to configure contact in TF, apply, activate/verify SMS contact in UI and then use the contact in TF configuration in some resources and then apply once more. I am not sure, what TF would report, if the contact would be inactive and some resource would be configured to use it. But IMHO it's better to do two-step configuration and have contact configured in TF too.

The API returns instantly with OK. It sends the SMS instantly too. The contact is created as inactive and user has to go in UI, click "activate" button and enter SMS.

Maybe notice about two-step configuration should be made, but it would be grate to have sms-contact configuration in TF too.

Thank you! :-)