Where SMS is going to be deployed in an enterprise environment, it may not be feasible to have a web port accessible to be given the message via HTTP POST - in this instance it would be beneficial to have other options available such as:

Additional HTTP commands for:

List messages in queue
Retrieve message X


Additionally, there are other protocols which would be ideally suited to this scenario as another option such as POP3 or IMAP, making the inboxes available via POP3 would also then make a seamless integration to email systems without them needing to be forwarded in to an existing email system.

Regards
Matt.

Thank you for your post.

We have made deliberate decision not to include interfaces for retrieving and polling for new messages. We have done this as these types of interfaces our often used in such a way as to create a large server load (e.g. polling 10 times per second), and therefore not scalable.

I would recommend using HTTP forwarding and storing messages in your own database locally. You will then be able to query your database as required.

Alternatively, use our Outlook SMS addin to provide 2 way SMS with in a enterprise environment.