ThingSpace Connectivity Management API Callback Testing

Discussion created by richardscafuto Employee on Jul 17, 2017

Setting up a callback service can include multiple layers of required pass through to your server.

  • Does the server have a virus application blocking inbound traffic?
  • Does the server have a firewall application blocking inbound traffic?
  • Are there internal firewalls along the inbound path to the server blocking inbound traffic?
  • Is the ingress router and firewall blocking the inbound path?
  • Do you have a specific port policy or route policy in place to permit or deny the inbound traffic?


Once you are sure the inbound path is clear you can check your service.

  • Can you get to to the service locally on your machine (
  • Can you get to the service from another machine on your network?
  • Can you get to the service from another machine off your network?
  • Should you be able to get to your service from any other place, other than Verizon, due to a specific route policy?


You can test your callback service using PUT /devices/actions/customFields. 

  • You need to have at least one active device on your account.
  • It provides a fast callback response to your request.
  • It changes one of the five available custom fields and does not affect your device, line or account.
  • It uses the CarrierService callback, the same callback service used for activations.
  • It can be used again and again.  Preferably with a variable that sets the time or increments a number for easy identification of changes.


Testing suggestions.

  • Test your http callback first, confirming inbound is operational.
  • If you require a secure connection, once http is confirmed then move to testing https.  
  • Https requires a legitimate signed security certificate.  A self signed certificate will not work.
  • If you require additional security, your can try adding the username and password option.


Read more about registering callback services at ThingSpace Callback Services.