Avinode API Service Constraints and Limitations

• Definitions: Customer – end client of one of our members that is looking to charter an aircraft and might also be a passenger on the trip. Member – An Avinode customer and member of the Avinode marketplace.
• Avinode’s General Terms and Conditions and API Terms and Conditions need to be accepted as a set by the Member.
• Avinode develops APIs on a common use basis. There is no exclusivity clause that Avinode will accept.
• Avinode will protect the business model of the Member by not revealing details of the implementation to other prospective or current Members.
• Avinode can publicly communicate that Avinode is supplying an API service to the Member.
• The Member application must include attribution to Avinode according to the Avinode API Branding Guidelines.
• An API client must be a Member. It is not possible to use API services without a valid membership to the Avinode Marketplace.
• A non-solicitation clause is in place that states that the Avinode API Member may not approach a member of Avinode for the same data as Avinode provides as part of the API Service during the Member´s membership or for a period of 1 year after membership was terminated to power the Members application, web site, backend system etc. in similar manner as when using the Avinode APIs.
• Avinode does not allow any API implementation to result in a re-redistribution of Avinode content to the existing Avinode community of brokers, operators or marketing agents.
• Avinode will consider on a case-by-case value the distribution of Avinode content to other businesses where they are outside of Avinode’s existing network.
• Some form of request or lead process must be in place before the Operator name and tail number is revealed, so operator name or tail number cannot be shown in public sites eg. an initial search result can never include operator name or tail number.
• Avinode only allows data to be stored for the purpose of supporting specific tasks.
  Where push notifications are used to maintain a database of Empty Leg flights, this must be via a SYNC of data to ensure that an up-to-date version of the data exists on the client side.
• Avinode does not allow any data collected by the APIs to be given, bartered, sold to third parties, etc.
• There will be no limit to the number of push notifications that Avinode will support.
• A push notification does not require that a customer has requested it.
• Push notifications can be distributed by the Member and can be pushed across multiple devices.
• Where Avinode supplies content, Avinode will want to know how many times this content has been displayed to the customer or end client. This concept is call a touch.
• When Avinode introduces a booking process, Avinode will give notice to Members to incorporate to this service.
• For internal implementations, Avinode will record that Avinode has pushed an empty leg to that customer.
• Avinode will supply any data point that Avinode can generate, subject to legal or contractual constraints.
• Avinode will build heuristics capability into the services over time.
• Member Applications must be intended for use by humans, not machines.
• Access to the API Services is granted to the Member on a subscription basis.
• Each API Service has a maximum rate limit regarding the number of data calls allowed within a period of time.
• The Member may not create a “wrapper” or offer any other software layer or API on top of the API Service that hides the presence of the underlying API service.
• At all times the Member must use the most recent version of the API Services.
• As Avinode provides new functionality, API Members will need to keep pace and upgrade their application.
• A Member Application may only be distributed after it has been approved by Avinode.