While Gatekeeper enables sophisticated website configurations, the complexity mostly lies in Gatekeeper itself and secondarily, in the policies. The actual technical integration will be fairly light.
After your team has finished the first six steps of the Getting started guide, what remains is having your web server check Gatekeeper when deciding how to respond to incoming web requests.
When a visitor makes a request to your web server, have it call Gatekeeper's Visit authorization endpoint and pass in information about the visit: the visitor's IP address, the URL of the requested page, the user ID (if applicable), and the user agent string. Gatekeeper will generally respond in one of three standard ways:
|"allow"||Show the user the requested web page.|
|"deny"||Do not show the user the requested web page. Instead, show the user a different page, which might be a paywall or some other explanation. Note that there is an optional reason field that your team might want to display to the user.|
|"captcha"||Do not show the user the requested web page. Instead, show the user a CAPTCHA challenge. When the user submits a solution, let Gatekeeper know whether the user successfully answered the challenge or not via the Visit CAPTCHA status endpoint. Even if the user fails the challenge, be sure to let Gatekeeper know since some policies consider the number of CAPTCHA failures.|
Your team might also want to use custom authorizations, in which case you'll also want to craft responses for each custom authorization.
If your site has the concept of premium members or subscribers and membership in that set changes as people sign up or let subscriptions expire, you'll want to update Gatekeeper about the changes in membership via the Visitor Groups endpoint. For more information, see the tutorial on whitelisting.
If you want to show users how many free articles they have left, you can see how many visits a user has accumulated per policy using the /gatekeeper/visits/count/for-policy endpoint.