I know you are the one who is going to respond so directing it to you straight away.
Are you planning to introduce sandbox environment to the development cycle? Currently we have to test on the production databases of the QuickFile, it would be great to not messing up with my company’s real accounting data and just have sandbox where we can play around and test integrations. If not, it would be great to have at least option to delete testing data forever. At the moment they are still present in the delete category, quite lot of it (I was testing extensively).
How can I receive the news about API changes? Is there any mailing list? Recently, you have introduced ApplicationID which I wasn’t aware of therefore our code got broken.
Thanks in advance for the response.
Thank you @BanksyBoy. I know about this testing tool but this is more for XML syntax correctness. I need something however that is not stateless (i.e. keeps data in the database so I can integration test whole lifecycle of the invoice).
Fair enuff! All the best with that
I agree that having some flag for test data that can be easily rolled-back would be useful, but it’s technically quite difficult for us to add this now and would involve significant modifications to some core procedures in the system. It’s just something we don’t have time to do right now. I would suggest instead just setting up a test account and limiting all your test calls to this account. Or if you haven’t yet got any important data in your account you could use a live account then run the account-wipe procedure once you have completed testing.
Deleted invoices are never completely purged (unless you run the account-wipe procedure mentioned above) as to keep a clear audit trail. For this reasons it’s also well worth having a separate test account.
This is one of the main reasons we introduced the Application ID field, we now have a single point of contact for app developers so we can notify you in advance of any changes. Actually we had that very problem giving current API users advanced notice of the change that broke your code. We are no able to provide ample notice, although we would be making code breaking changes like this in the future, this really was an exception.
Thank you. Good response. I think I will setup my own ‘testing’ account if its free of charge. Keeping all data for audit trail seems reasonable, I wasn’t thinking of that.
Regarding the API changes, it would be great to have RSS or some mailing list were we can subscribe to receive changes.
You can follow the Extensibility category, this is where we will discuss any new API related features and updates. I’ve pinged the guys who run the forum to see if there is a way you can subscribe to an email digest on any posts made just to this category.