Overview
Essentially communication between ActiveMember360 and ActiveCampaign can be achieved using two methods either by the ActiveCampaign API or by webhooks.
API
API stands for Application Programming Interface.
ActiveMember360 uses the ActiveCampaign API for two purposes:
- To provide ActiveCampaign with the latest data. For example, if a tag is added to the logged in user within WordPress ActiveMember360 requests using the API that a tag be added to the relevant contact in ActiveCampaign and receives as a response whether this operation was successful or not.
- To pull data from ActiveCampaign for use within the WordPress site. For example, upon login ActiveMember360 requests from ActiveCampaign all data related to the contact email address associated with the user who is attempting to login and receives all ActiveCampaign contact data as a response.
In both cases ActiveMember360 makes a request to the ActiveCampaign API and will then receive a response.
So, think of an API request and response as the software equivalent of using directory enquiries. You ask for a phone number for someone and the response by the operative provides that.
Webhooks
When using a webhook no request is required. A webhook just sends the data when it’s available.
In this case the data is pushed to the WordPress site running ActiveMember360 automatically by ActiveCampaign.
The webhook is a way for ActiveCampaign to provide ActiveMember360 with real-time information. A webhook delivers data as it happens, meaning the most current data is available immediately.
So, this is the equivalent of being sent a new phone directory automatically every time someone is added to the directory, or their details change.
ActiveMember360 could use the ActiveCampaign API to ensure it is always working with the current data. However, as ActiveMember360 has no way of knowing when data has changed within ActiveCampaign it does not know when to make an API request for the current data, meaning it would have to continually send API requests to ensure all was current. A very inefficient process.
This makes webhooks much more efficient for this purpose than continual API requests.
When the webhook is executed it will make a HTTP request (typically a HTTP POST) to the ActiveMember360 WordPress site, and ActiveMember360 then updates the local contact data for immediate use.
Unfortunately, webhooks can make a lot of requests, i.e. HTTP POSTs, if a lot of changes occur within ActiveCampaign. The volume of HTTP POSTs received may cause all server resources to be consumed, and/or be considered a DDoS (Distrubuted Denial of Service) event.
ActiveCampaign Webhooks & ActiveMember360
In the case of ActiveCampaign, webhooks can be executed and HTTP POSTs sent either from within an automation using the Webhook option, or automatically by webhooks being triggered from ActiveCampaign events.
The event triggered webhooks are those defined in ActiveCampaign, Settings, Developer, Manage Webhooks. By default, ActiveMember360 automatically sets up a webhook in that area if within WordPress ActiveMember360, Webhooks is set to Yes/Enabled. These webhooks are configured to trigger whenever a contact is added or updated in ActiveCampaign.
The event triggered webhooks are totally controlled by ActiveCampaign. No third party vendor can change the behaviour of those webhooks.
ActiveMember360 uses the HTTP POSTs sent by event triggered webhooks to keep data current and to automatically trigger password generation for contacts
It is typically the HTTP POSTs sent from event triggered webhooks that can cause a flood of HTTP POSTs to the server hosting the WordPress website. That is because bulk updates of any kind to contact data can trigger these webhooks.
So, to avoid that situation configure ActiveMember360 to not use event triggered webhooks.
With event triggered webhooks switched off the current ActiveCampaign data should be pushed to WordPress using automation webhooks.
To do that ensure within WordPress ActiveMember360, Webhooks is set to No.
Then if either of the following are required:
- Generate a password
- Ensure contact data is current for a logged in user where it may have been manually changed within ActiveCampaign, or changed by a third party application, or changed by actions in an automation
use a Webhook URL set within an automation.
In both cases use the ActiveMember360 mbr_genpass module within the webhook URL as detailed here:
This option gives total control over when webhooks are used to send HTTP POSTs. Obviously, significant numbers of contacts should not be sent through the automation at the same time, as this could result in the same issues as using event triggered webhooks.
Please note where ActiveMember360 changes the contact data these changes are always current within WordPress and there is no need to use any webhook.
So, regarding the use of webhooks the choice is with the user of ActiveMember360.
Either use automatically configured webhooks which may result in high volumes of HTTP POSTs being sent to your server, or manually configure webhooks for more control.