We encourage thorough use of the functionality of the Access MicrOpay Web API, but there are restrictions to how the Access MicrOpay Web API may be used to protect the speed and security of our systems.

Security

The Access MicrOpay Web API has been designed with security at its heart. It is vital that Software & Service Organisations take this security as seriously as we do, because it’s the clients data that is at risk if security holes are created.

In order to use our Access MicrOpay Web API, Software & Service Organisations will need to determine the domain they will be using to connect to our Access MicrOpay Web API. With this extra layer of security our clients data is kept safe, and you have a safety net against advanced hacking methods that may get hold of these credentials.

You must be very careful with how your applications authenticate with the Access MicrOpay Web API. You must firstly make sure there is no way to inspect your code or DB to get a password/list of passwords for connecting to our Access MicrOpay Web API. Examples of what you must avoid include:

• Hardcoding the credentials in a web page or application
• Storing a list of passwords in a database that you distribute to clients
• Same applies for the api key for each client

The Access MicrOpay Web API operates over SSL, using Go Daddy certificates. Backend software development tools should allow you to verify this certificate when using the Access MicrOpay Web API. In this way, you can avoid another software acting as our Access MicrOpay Web API in order to get you sending them sensitive client data. Connecting to this SSL should only be possible using SSL if you are accessing the Access MicrOpay Web API directly from your web site.

Request limits

We don’t to make it difficult to use the Access MicrOpay Web API for all your needs, but we ask you to respect the fact this system is to be used for a large number of Software & Service Organisations and clients, so proper usage will lead to fast access for everyone.

At this stage, we will not be enforcing any hard limits, but will be monitoring for unusual behaviour. Here are some examples of what we expect to be fair usage of the system:

• Employee Change Requests should be made only when there are changes, ie not sending all employee data every day.
• Checking for Employee Detail changes from a Access MicrOpay database should not happen more than every 30 minutes, or on demand from the user interface.
• You should be able to locally cache Employee Details and Lookups rather than use our API as a lookup table every time someone looks at an employee entry screen.
• If you do have several Employee changes to send, they should be sent one at a time synchronously, or with a gap between each request.

In general try to think of the usage scenarios of your Access MicrOpay Web API calls and optimise it for your product, while thinking about the possible impact it has on our Access MicrOpay Web API. We want your product to be amazing, and part of that will be having fast access to our API for yourself and everyone else.