This article covers how integrating with OnlineFundraising could look, as well as attention points. A starting point for selecting an integration model would be to get an overview of the data present - or soon to be present - in OnlineFundraising. Depending on the amount of data your organisation works with, how much you intend to scale up, and how often data needs to be processed, different requirements are posed for an integration with OnlineFundraising. Keep reading to learn more about:
> If you are a developer and you are developing or about to develop an integration with
OnlineFundraising, please refer to our full API Documentation.
2. When to integrate?
Integrating with OnlineFundraising is not a requirement in order to use the system. OnlineFundraising supports exporting data as files as standard, in order to support processes such as:
- Bookkeeping payments within a specified time interval
- Call lists consisting of phone numbers, e.g. of contacts who sent a text message to a specific keyword
Read more about how to use the export module in OnlineFundraising in our support guide.
When creating exports of data manually it is important to note that the export job takes longer the more data you intend to export. Another important note is to keep track of processed data versus unprocessed data. Hence, you should consider how these manual processes are handled within your organisation - and more importantly when they should be automated.
3. Meet our integration partners
The OnlineFundraising team is happy to facilitate the conversation between you and your organisation's integration partner. Read more about our existing integration partners here.
Integrating with OnlineFundraising requires an understanding of the advanced datamodel and API overview. Please read this article if you are a developer. If you are not a developer, you can skip the prerequisites.
5. Integration models
5.1. Scheduled integration
One integration model is to fetch data regularly from OnlineFundraising. OnlineFundraising's API supports making requests for batches of data which can be scheduled, for instance every night. It is possible to filter the requests in order to get e.g. all records created within a specified time interval.
This model is useful if fetching data is not required very often. For instance, it is useful if data needs to be represented in a dashboard or a report, where data only needs to be refreshed once per day or on demand.
When choosing this approach, the following points should be noted:
- Scaling of integration. A request can fetch up to 100 records at a time, which means that the integration most likely needs to support pagination (fetch the next 100 records). The amount of requests tends to increase rapidly.
- Manage which data has already been processed. Identifying records that have been updated after a record was processed is usually a challenge, so it worth considering the use case. In addition, you should consider how a request is handled in case it fails or stalls.
This integration model can handle medium to large amounts of data, but you may need to take action in order to scale better if the requirements for how frequent data is fetched changes.
5.2. Event based integration
OnlineFundraising support sending webhooks triggered by an event in OnlineFundraising. En event could for instance be that a subscription is updated or a payment fails. See all event types here.
Using webhooks, the integration only needs to call the API when it is relevant and for the specific record the event pertains, making it possible to create an integration where data is processed continuously. OnlineFundraising recommends this integration approach.
This approach to integration is especially useful if your organisation intends to react on an event which was registered in OnlineFundraising, for instance by starting a marketing automation flow, call the Contact, or send personal communication - all of these from an external system.
Attention points for this type of integration:
- Manage which webhooks have been processed. Consider as well how the integration should handle a failure of processing a webhook.
- Webhooks are asynchronous. The order with which webhooks are sent is not always equivalent to the chronological order of events. In other words, you may receive a webhook in the event a Contact was updated - before you receive the webhook in the event that the same Contact was created.
- Integration scaling. Webhooks are sent continuously, and there will be times where more webhooks are sent out than others. If a webhook is not successfully delivered, OnlineFundraising attempts to send it again a couple of times. In other words, the integration should take into account fluctuation in the amount of webhooks received.
Note that it is possible to send webhooks retrospectively for past events.
5.3. Embedding OnlineFundraising
It is possible to embed iframes that point to specific records in OnlineFundraising, for instance a Contact or an Agreement. An iframe such as this could be embedded in a CRM-system. The benefit of embedding OnlineFundraising iframes is that the user of the external system can see and interact with data directly in OnlineFundraising without having to switch between systems or using an integration.
Combining an integration with OnlineFundraising with embedding iframes often proves useful.