1. Home
  2. AccessAlly
  3. CRM Automations
  4. Webhook Guide: How & When To Use Them

Webhook Guide: How & 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.

List of Webhook Commands:

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

aal_genpass: Generate new member

What it does: Creates a new member if it does not yet exist, and generates a password. If member already exists, it will update all the data, without overwriting the password.

When to use it: When there’s a purchase or opt-in from outside of AccessAlly, after you apply access tags. Only use this webhook when there's a chance this contact does not exist yet in AccessAlly.

To update a contact's information, use the next webhook (aal_updateuser) instead because it is a lighter operation and will not slow down your campaigns.

aal_updateuser: Update existing user

What it does: Tells AccessAlly to pull all of the latest information about this contact, including tags and custom fields.

When to use it: Run this webhook whenever you apply or remove a tag, or update a custom field in your CRM. This is the most commonly used webhook!

aal_fieldop: Run custom operations

What it does: Triggers the custom operation that you’ve set up in AccessAlly.

When to use it: As part of an automation campaign, for example when implementing a gamification points system.

Parameters: operationId: the ID for the custom operation you want to trigger.

aal_initiateteam: Initiate a team

What it does: Creates a new team with this contact as the team leader, for the specific team program.

When to use it: If you want to initiate teams through your CRM because payment is being made outside of AccessAlly.

Parameters: teamId: the ID for the team program.

aal_deleteteam: Delete an entire team

What it does: Removes the team leader and all team members from the team program, and revokes access by applying revoke tags. It does not delete the contacts themselves.

When to use it: If a team is not renewing, or asks for a refund and you want to remove the members from the team and access to the content.

Parameters: teamId: the ID for the team program.

aal_removeteam: Remove a team member

What it does: Takes a team member off a team, so that seat can be returned to the pool of available seats. This member will no longer have access to the content associated with the team.

When to use it: When a team member is no longer a part of the company, or needs to be replaced.

Parameters: teamId: the ID for the team program.

aal_updateteam: Increase or decrease team size

What it does: A positive number increases the team size, and a negative number decreases available seats on a team.

When to use it: If someone purchases additional seats, or you want to expand or contract the capacity of a team based on other criteria.

Parameters: teamId: the ID for the team program. change: the amount you want to increase or decrease the team size by.

aal_teamops: Run a team interaction

What it does: Team interactions are set up for each team program, and can be used to apply tags or run custom operations on individual team members.

When to use it: To give members gamification points, grant access to more content, or run any other type automation.

Parameters: teamId: the ID for the team program. opId: the ID for the operation you want to run.

AccessAlly Payment Webhooks

If you are using AccessAlly's built-in payments, then you will also be able to use the following webhooks to manage subscriptions and create fancy coupons.

aal_createcoupon: Create a one-time coupon

What it does: Creates a member-specific coupon that is stored in a custom field, and expires after use or a given timeframe.

When to use it: Once you’ve created the placeholder coupon settings under Sales -> Promo Setup, you might run this and include the coupon in an abandoned cart campaign or a sales promotion.

Parameters: promoId: the ID for the promotion you set up.

aal_revokesubscription: Revoke an AccessAlly subscription

What it does: This immediately stops an AccessAlly subscription, and applies all of the revoke tags to remove access for this contact.

When to use it: When someone asks for a refund, or if set up an automation to remove access after a failed payment has not been recouped within a certain timeframe.

Parameters: productId: the ID for the subscription product in question.

aal_cancelsubscription: Cancel an AccessAlly subscription

What it does: This stops future payments from being charged, and will remove access at the end of the current payment period.

When to use it: When someone wants to cancel, but keep access for the amount of time they have already paid.

Parameters: productId: the ID for the subscription product in question.

aal_adminstopsubscription: Pause an AccessAlly subscription

What it does: This pauses a subscription so no future payments are charged, and it does not affect access.

When to use it: If you want to give people access without charging them on their current schedule.

Not compatible with PayPal subscriptions.

Parameters: productId: the ID for the subscription product in question.

aal_chargesubscription: Charge outstanding balance on an AccessAlly subscription

What it does: Attempt to collect payment on an outstanding balance, which might accumulate after a failed payment.

When to use it: As part of a failed payment campaign where you ask members to update their payment information first.

Not compatible with PayPal subscriptions.

Parameters: productId: the ID for the subscription product in question.

aal_batchsync: 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 18, 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.