1. Home
  2. AccessAlly
  3. CRM Automations
  4. [Guide] Webhook / HTTP post Commands & When To Use Them

[Guide] Webhook / HTTP post Commands & When To Use Them

A webhook is one method that allows communication between web applications. It allows you to send data from your CRM to AccessAlly when certain events occur.

This allows your two systems to stay synchronized with each other.

Why use a webhook?

A webhook can be used when there is no other way of accomplishing what you are trying to accomplish.

For example, if there is no direct integration between two applications, then a webhook may be the best way to get them to talk to each other.

With AccessAlly, webhooks are commonly used in your CRM automations.

One common use case would be creating a password on your AccessAlly site for a user when the CRM adds a tag to their profile.

Webhooks are very complex, as they allow you to accomplish many things. Understanding how they work can help you troubleshoot WHEN (not if) an issue comes up.

When webhooks are created it is done so by an application, it must then travel through the server hosting the application, into the internet, through many routers, to the server hosting the application it is being sent to, down to the application itself. This second application will then do what is requested (such as generate a password), and then send a response back through the same system. Application, server, internet full of routers, server, application.

Common Reasons Why Webhooks Fail

Your webhook can break at any point along this path.

This is why it is so important to troubleshoot each webhook as its own unique problem. This is also why it is important to involve other parties in the troubleshooting process. Usually, you will have access to the application on each end, but you may not be able to see anything in between. This is why we ask for the CRM to look at their logs to determine what they show. It’s also why we ask to have logs looked at by your website host, as usually only they can see them.

The combination of getting everyone involved will usually lead to figuring out where the disconnect is. For example, if the CRM shows that no reply was received, but your website logs show it received the webhook from the CRM, then it means the return path was broken somewhere. It may have been at the website host level, perhaps they blocked it for some reason, perhaps it left the webhost, but was not received at the CRM in the CRM’s allocated time. Each CRM listens for a response for a different amount of time. ActiveCampaign for example only listens for 5 seconds.

Perhaps the server received so many webhooks at one time that it did not have enough resources to process them all at once, this can also cause errors. Errors that can only be seen from the web host logs, not from AccessAlly. This is especially true of shared hosting, as the server resources are shared amongst a number of websites. Some web hosts even make it a habit of regularly putting 400+ sites on a single server. When this occurs, webhooks will fail more often. This is why AccessAlly offers different webhooks for different purposes.

Only once all the information has been collected and the actual failure point has been established can it be corrected. The correction may involve using a different webhook that is not as server resource intensive, it may be getting your web site host to change a setting, or increase server resources, it may be fixing a typo in the webhook, it may be that the CRM made a change and blocked it, it may have been blocked at a router (very uncommon, but could happen), it could be ANYTHING.

When possible, use another solution

Whenever possible we recommend not using webhooks at all, and instead using built-in AccessAlly functionality. This will help ensure a much smoother process.

How can you do that?

Take orders using AccessAlly order forms, and make sure the Offer is set to create an account for the user (this eliminates the need for a genpass webhook). This will generate their password and send it back to the CRM immediately, so you can still send the password in an email if you want to. This option also allows you to display their newly created password on the screen after successful purchase and then send users directly to the course. This is a fantastic onboarding experience. Note: This will not generate a new password when an existing user makes a new purchase.

If using optin forms for free access, use the On-Demand Login feature of AccessAlly as part of the thank you process. This will again generate a password for a first-time user and send it back to the CRM. Note: The On-Demand Login will not work for existing users, due to security reasons, they will need to login with their existing credentials.

Finally, if migrating from a different solution, or adding a bunch of users at once manually, do not run them through a webhook. Use the AccessAlly Migration plugin to create their accounts. This creates the accounts on WordPress and pushes them to the CRM, which is less intensive than webhooks. Note: if you have an email address for an existing user in the migration upload, it will not generate a new password for them.

How to Create a Webhook in Your CRM

The base URL of your HTTP post/webhook can be found in AccessAlly > General Settings > Initial Setup

The bracketed portion of the webhook is replaced by a specific command (the full list is found in the table below).

Special Notes for Individual CRMS:

INFUSIONSOFT/KEAP - PLEASE READ

When adding an HTTP post to your automation, the Contact ID is already included in the Infusionsoft settings.
All you need to do is copy/paste your Webhook URL as outlined in this article.


ONTRAPORT - PLEASE READ

When adding a webhook to your Ontraport automations, you will have to add the Contact ID for the webhook to work:

The post data is [Contact ID]

Please note: there must NOT be a new line at the end, or it won't work.


CONVERTKIT - PLEASE READ

Because of limitations in the ConvertKit system, it is currently not possible to create a webhook directly. Please see this article for in-depth instructions: How to Create ConvertKit Webhooks.

Types of HTTP Post / Webhook Commands:

The bracketed [operation] portion of the URL is replaced by any ONE of the following commands:

aal_genpass This command generates a unique password for a user. Typically used in sign up/purchase automations.
aal_updateuser This command syncs permission tags for a user. Typically used only when updating permission tags for a SINGLE user.
aal_batchsync This command also syncs permission tags for a user. However, it is typically used when updating permission tags for MULTIPLE users.
aal_fieldop This command is typically used in a CRM automation for one of AccessAlly’s Custom Operations

If you are using the AccessAlly order forms, you will also be able to use the following:

aal_​revokesubscription This will revoke (immediately stop) an existing subscription.
aal_​cancelsubscription This will cancel an existing subscription, which means that the user's card will not be charged for future payments.
aal_chargesubscription This will charge any outstanding balance for an existing subscription.
aal_createcoupon This will create an one-use coupon for a promotion.

Batch Sync Users (Advanced functionality)

The aal_batchsync operation is designed for a "timed" program release. A "timed" program release is configured when a group of clients receives new permission tag(s) at the same time.

An example of when you'd use this type of webhook is for a very specific case scenario.

You're running a 30-day stage released course. You have a large number of participants (1000+) that will unlock a new day of content at exactly the same time on the same day.

Because so many people are running through a campaign in your CRM at the same exact time (9:00 am EST) on the same exact day (Monday) using a traditional updateuser webhook is likely to fail due to the number of people moving through the CRM at the same time. When the updateuser webhook fails it results in some contacts have access to the content and others report that they're not able to view it.

In this case, you will want to use the aal_batchsync webhook, which will tell AccessAlly to request refreshed information for each of the members.

You may also want to use Client Driven Updates within your emails (and for some CRMs this happens automatically). Email Click Detection is another way to have large numbers of contacts moving through your campaigns.

Email click detection is used in addition to a batchsync webhook, and is in place to make sure no member goes to a page that they don't have access to, when they should.

How To Use It (example)

For example: a new module with permission tag "Module_3_Has_Access" is going to be released for 500 clients next Monday at 8AM EST.
At this time, the tag "Module_3_Has_Access" will be added for all 500 clients inside your CRM. The CRM automation will then notify AccessAlly that all 500 clients must have updated permission/access inside the membership site.
The volume of this HTTP request can cause a strain on the server resource. This may cause some of the requests to be bounced and not be completed, depending on the server's capacity and security setting.

The "aal_batchsync" HTTP operation works around the issue by introducing a short delay (5 minutes) between AccessAlly receiving the update request and when it actually performs the synchronization, so the heavy duty operation is performed after the HTTP Post / Ping URL requests.' section_head_2='How to Use It' section_content_2='

"aal_batchsync" is configured very similarly to "aal_updateuser" in a Campaign (Infusionsoft) / Sequence (Ontraport) / Automation (Active Campaign).

After the permission tag(s) have been added, we can add a HTTP Post (Infusionsoft) / Ping URL (Ontraport) / Webhook (Active Campaign).

Because there is a delay between when AccessAlly receives the request and when the synchronization is performed, please allow a 30-60 minute delay (depending on how many users you have in the system) before sending the welcome email to the clients

Example Setup - Infusionsoft

To release the module at a specific time, the campaign needs to have 2 sequences: one to add the permission tag, and optionally another one to send the welcome or release email.

batchsync-ifs-campaign

In the release sequence, we will add the permission tag and send the "all_batchsync" HTTP Post.

batchsync-ifs-release-sequence

For the HTTP Post, the Post URL is (you can get the URL from AccessAlly -> General Settings -> Initial Setup -> System Integration)

http://site.url/?aal_batchsync=[handshake]

batchsync-ifs-http-post

Optionally, you can send a welcome or release email after waiting 30-60 minutes.

batchsync-ifs-email-sequence

Example Setup - Ontraport

To release the module at a specific time, the sequence needs to have 3 tasks: one to add the permission tag, one to notify AccessAlly, and optionally, one to send the welcome or release email after waiting 30-60 minutes.

batchsync-otp-sequence

For the Ping URL rule, the Post URL is (you can get the URL from AccessAlly -> General Settings -> Initial Setup -> System Integration)

http://site.url/?aal_batchsync=[handshake]

batchsync-otp-ping-url

Example Setup - ActiveCampaign

To release the module at a specific time, the sequence needs to have 3 actions: one to add the permission tag, one to notify AccessAlly, and optionally, one to send the welcome or release email after waiting 30-60 minutes.

batchsync-ac-sequence

For the Ping URL rule, the Post URL is (you can get the URL from AccessAlly -> General Settings -> Initial Setup -> System Integration)

http://site.url/?aal_batchsync=[handshake]

batchsync-ac-webhook

Troubleshooting a Slow Batch Sync

If you're running a batch sync through your CRM, but it's taking longer than 30-60 minutes to process all of the update requests through AccessAlly, it might be a setting on the web hosting server that needs to be updated.

Please contact your web hosting provider for your AccessAlly site, and ask to switch to a "system task based cron" so that the batch sync process runs quickly and efficiently on the server.

For example, the WP Engine Alternate Cron is a true cron that runs every minute on the minute, checking for and activating scheduled events. This is not enabled on your server by default, so you will have to request to have it enabled via Support.

Learn how AccessAlly reduces server load with webhooks and activity-based updates.
Updated on March 2, 2021

Was this article helpful?

Related Articles

NO QUESTION GOES UNANSWERED

If you have any questions, we're just an email away.

We take your success seriously, and you'll always get a speedy reply from a real person during business hours.

Opt-In-Laptop.png

AccessAlly is the #1 WordPress Course and Membership Solution for Industry Leaders

WATCH THE DEMO

You'll get follow-up emails about AccessAlly and new features. Opt out anytime. Full privacy policy here.