iMIS Third-Party Developer Guidelines

Overview

As an iMIS third-party developer, it’s your responsibility to understand the system architecture behind the iMIS Enterprise or Professional Engagement Management System (EMS) and communicate to your client how the integration you’ve built interacts with their iMIS systems. Adhering to the following will help you and your client be successful.

Guidelines

iMIS is a fully integrated cloud engagement system built for non-profits. Given its extensive interconnectivity between modules, ASI does not have the ability to troubleshoot 3rd Party Integrations however you are welcome to post general questions on our iMIS SDK site in one of the discussion forums. (developer.imis.com)

iMIS RESTful API

Third-party integrations must use the iMIS RESTful API to future proof your application or integration and to ensure it is cloud friendly and will not break after frequent iMIS upgrades. Any type of application that inserts or updates data in mass should only do so via the API.

Third-party developers must make it clear to clients that your application or integration is unsupported by ASI, and that performance and reliability is the sole responsibility of the application developer.

Client Side iParts

The iMIS EMS System uses iParts. Any custom iPart should follow best development practices as outlined in the iMIS Developer SDK Website. (developer.imis.com)

API Usage

Currently there is no cost to use supported API endpoints for existing clients. However, we reserve the right to bill for non-standard usage and custom development.

ASI monitors API usage to prevent excessive traffic during peak times. Please exercise good judgment in the development of your code and reach out to us if you have any questions about efficient use of our APIs.

Should usage appear to significantly exceed that norm on a regular basis, we may contact you to investigate and resolve the matter. In the event of excessive usage outside of normal patterns we may temporarily suspend or disable your work but will make a good faith effort to contact you and any impacted clients prior to acting.

API Encoding Headers

When creating third-party integrations consider adding compression methods like gzip or deflate to your HTTP request headers. For example: Accept-Encoding: gzip, deflate Inserting the compression header into your API requests will optimize bandwidth and improve the overall performance of the third-party integration by reducing the payload size that comes back from requests.

Payment Gateways

For Payment Card Industry (PCI) compliance and security, the payment gateways included in iMIS Pay Central are the only supported payment system allowed in post 2017 GA versions of iMIS. In other words, non ASI supported gateways are not allowed.

Follow UI/UX/WCAG Best Practices

Beauty is in the eye of the beholder but strive to follow the clients’ patterns, responsive theme, CSS, and other design elements to make your third-party application looks as though it is designed to be a part of iMIS EMS to limit confusion on the user’s part. iMIS incorporates WCAG. 2.0 Level AA accessibility standards and your applications should as well.

Developer Resources

• iMIS SDK Site (developer.imis.com)
• iMIS Documentation and Help Site (help.imis.com)
• iMIS Developer Courses (https://www.advsol.com/training)