Webhooks are a way for Gradual to send real-time data to another system when a specific event occurs.
How Webhooks Work:
Event Triggered: Something happens in Gradual (e.g., a new user signs up or user registers for an event).
Webhook Fires: The system automatically sends an HTTP POST request with data to a pre-defined external URL.
Receiver Handles It: The receiving server (your app or service) processes the incoming data and takes action (e.g., update a database, send an email).
Example Case Uses:
User checks into an event → Add a new record to Airtable
User leaves a space → Send a notification to Slack (e.g., alert the ops team)
Community application is accepted → Update the applicant’s status in your CRM or another connected system
Community application is declined → Send your own decline communication or update the applicant’s status in your CRM
Gradual also supports a waitlist join webhook event. When a user joins a waitlist, the webhook sends type: userJoinedWaitlist and dateOfJoin.
Gradual supports webhook events for community applications when an application is submitted, accepted, or declined.
The communityApplicationSubmitted webhook is triggered when someone successfully submits a community membership application, allowing you to start a review workflow before approving the applicant. The payload sends type: communityApplicationSubmitted and includes dateOfApplication, the applicant’s userEmail, and applicationQuestions, which contains each application question and the applicant’s response. Answers to single-choice and open-ended questions are returned as text, while answers to multiple-choice questions are returned as a list of the selected options.
The communityApplicationAccepted webhook is triggered when an admin accepts an application as a standard member, limited approval member, or guest. This applies when an application is accepted from either the To be reviewed or Declined tab on the Application Requests page. If multiple applications are accepted at once, a separate webhook is sent for each application.
The accepted application payload sends type: communityApplicationAccepted and includes the application ID, the dates the application was submitted and accepted, the admin who accepted the application, and the membership type selected during acceptance. The acceptedAsMemberType value is returned as standard, limitedApproval, or guest. The payload also includes applicant information, the source of the application, and the applicant’s answers to application questions. userId is included when the applicant’s member account is available when the webhook is sent.
The communityApplicationDeclined webhook is triggered when an admin declines an application from the To be reviewed tab on the Application Requests page. If multiple applications are declined at once, a separate webhook is sent for each application.
The declined application payload sends type: communityApplicationDeclined and includes the application ID, the dates the application was submitted and declined, and the admin who declined the application. It also includes applicant information, the source of the application, and the applicant’s answers to application questions.
If someone submits a new application after the 30-day reapplication period, the new application receives a new application ID. Accepting or declining that application triggers the corresponding webhook for the new application.
No webhook is sent when an application automatically moves to the Expired tab. The accepted and declined webhook events are only triggered by an admin’s decision on an application.
When a new forum post is created, the webhook payload includes forumPostBody, which contains the full text of the forum post. If the post body is empty, forumPostBody will return as an empty string.
All supported webhook events and their payload fields are found here.