MyAllocator - has anyone tried it?

which was aquired by Digital Arbitrage, Inc. last year, as to be seen here
http://trademarks.justia.com/863/45/myallocator-86345562.html

Their current Todo List does not look like an easy six weeks job to go to make it available as a reasonable tool to be used in a productive environment again soon:

- Our Todo List

We are no longer allowing new clients to board under our legacy "antiquity" version(s) of the API.

This is a list of Errata. This page will list known areas we are working on, if you have a bug please let us know. This is our internal list of stuff we know is broken, or stuff we're working on.

NEED TO REGRESSION TEST v1
All calls need stricter incoming type checking, specifically at the container level.
PMS Property ID cannot be used as an identification.
Documentation: needs to be restructured, fix indenting, add Auth/PropertyId, designate container nodes using new syntax
Documentation: need to add new error codes, possibly create a severity measure.
Documentation: need to make list of channels and capabilities auto update
Documentation: need to implement test harness in API + fix API URI parameter strings
Documentation: need to fix title bar in API
JSON - planning to add _method, _version to the request (which must match URI) in next release 201412
Callback notifications for bookings cancelled via the API may be delayed, must be manually dispatched in staging environment.
Callbacks need to support versioning
propertyTokens are not fully implemented in all calls.
If you receive an internal server error, it is not always gracefully handled.
Error messaging on ARIUpdates on Channels needs to be improved. (Currently the same as legacy v1 API)
ARIUpdate ExcludeChannels is not working in JSON
AWS SQS notifications are not available in production (and will likely need some more live testing)
v1 compat - Need to discuss issues with overlapping date ranges (currently allowed on v201408, not on v1)
Loop Bookings: may not display properly in the interface (some date bug?)
Backend: Need to explore internal addState/useState on channels (is this even actually used?)
Backend: Need to move channel status logging from mysql to redis
Backend: Need to formalize the parameters/objects passed to upload_lt in each channel module for more legible internal codepath
Backend: Migrate MyAllocator->channel_update into the ARIUpdate framework
Backend: need to merge channel properties list in MyAllocator.pm into Channels.pm

If you want to see historical (recent) changes to the API our documentation is hosted on github. https://github.com/MyAllocator/apidocs

http://myallocator.github.io/apidocs/#api-_Appendix-Our_Todo_List

It is especially interesting to see that those who try to connect like they used to until last month are called "antiquity".

P.S.
I am still working on a community solution - like some others - to go around this and hope to have some good news within the next days/weeks.
:steve: ""Maybe you might even be thinking about supporting this?"" :steve:

I have compared extensively the following software companies in 2014. Just because I didn't go with one of these does not make them any less worthy than MyAllocator. However, for a small revenue hostel with 20 beds MyAllocator just fit the bill best. Do your own research and due diligence as the industry changes and companies get bought by competitors and sell quickly it seems.

MyAllocator (Mo & Mark) - https://www.myallocator.com/

Allocation software...aka Channel Managers:
DigitalRez International - http://digitalrez.com/
Charts PMS - (Nail was my rep) http://www.chartspms.com/
HostelOffice (Dean) - http://www.hosteloffice.com/
http://www.instantworldbooking.com/channel-manager.php
https://www.maxbooking.com/
http://www.vizergy.com/

PMS that I'm using - I also have BananaDesk https://bananadesk.com/ on trial:

Loventis (Martin) - www.loventis.net

Best of luck to all. I hope this information helps you!

Hi Peter

We are slightly confused over here. The old API is backwards compatible and not going away anytime soon. We would never remove any functionality without a huge advance notice. We recognize how valuable our PMS partners are and continue to be. That is why it became so important to address some long-standing issues in the API in the most expeditious way possible.

A few points in addition to your post:
* The v1 aka "antiquity" API has no end of life, we made a significant investment to make v1 compatible with all future versions.
* internally we don't even have a plan to deprecate v1 until well into 2016, maybe longer, it just depends on the adoption.
* v1 was _ridiculously_ hard for developers to implement, the success rate was extremely poor, the error handling was horrid, and, as a result, the integrations frequently were buggy.
* Yes, all of the call names were changed from VerbNoun to NounVerb so they would group nicely alphabetically, but all old call names (ex: SetAllocation vs. ARIUpdate) still work.
* we are going to continue to support both XML and JSON in perpetuity, and the XML data structures are identical (or nearly identical).
* we added functionality like UserTokens so you don't need to store passwords, this was the most highly requested feature, but there are many other improvements coming. The versioning capability is very important because it means we can roll out new functionality without impacting existing users. This is extremely important for desktop software systems which often can't deploy as quickly.
* So far all live PMS partners have been extremely enthusiastic about having userTokens so adoption is actually happening faster than we had anticipated, several vendors have switched over in less than a week, the current record is about 8 hours. We really tried to make this easy.
* We also unified the payment/booking calls which used json in v1, while all other calls used xml (this was a giant mess which basically meant every developer had to implement both xml and json). While we may also implement a HTNG/open travel version in the future there are no plans to deprecate this (since a lot of Hostel specific functionality isn't well handled by HTNG).

We'd like to have hundreds of channels, especially regional ones in the future and that just wasn't going to
happen with the way the old API/architecture was designed.

Hope that clarifies a few things.

Hi Adam,

Our site TravelExpo.ph is a new start up aggregator site for small hotels and travel agencies in the Asian region. Already some of our hotel members are asking us to allow integration of MyAllocator in our storefront pages which we offer to merchants. Does MyA also handle payments in the booking widgets offered?

Phil
TravelExpo.ph