We lost service today because we hit our transaction limit. This happened because our transaction reset date was changed when we upgraded plans. Per this thread:
our transaction reset date was October 29th.
According to this thread:
Upgrading our plan would not change our renewal date.
I received an email that we hit 90% of our allotment on October 29th, but since I "knew" our reset date was the 29th, I didn't take any action. I now know that the reset date was added to the my plan page, but since I don't look at that every day, I didn't know at the time.
I'm more than a little frustrated right now with the forum information not matching reality. It's been pretty clear to me that you weren't really ready for the rollout of these new plans.
Further, I certainly didn't have time to make adjustments to our software to minimize transaction usage. The annoucement was abrupt and there was no way I could allocate time to make the needed changes. The code I wrote was modeled after your api examples, which by my estimation, maximize transaction usage by creating a map first, then adding points, routes etc and re-zooming the map afterward to fit. Again, just another frustrating part of my experience here with a previously great and generous offering with the unlimited free open api.
I understand the need to charge for this offering, but I needed more time for transaction optimization - six months minimum. I also needed mature plan management system which just isn't there yet. I also need clear documentation on what constitues a transaction. The routing and geocoding are pretty obvious. What is less obvious is what constitues a map transaction. We have the very vague "40% of the map changes" but there is no way through the api for us to know when a transaciton is generated. I'm fairly certain we are generating 10+ transactions per map load right now but I just don't know for sure since there's no way to tie a map session to the number of transactions generated.