If you signed up before June 3, 2021, see the migration guide to learn about the recent API changes.

Edge integration

Integrating Castle at the edge with Cloudflare Workers or AWS Cloudfront Lambda@Edge

Sample implementations


You must have an active Castle account with a valid API key in order to begin using Castle at the edge. Sign up or retrieve your API key from the Castle Dashboard


  1. Set up edge listeners
  2. Capture request tokens
  3. Send Castle API requests
  4. React to Castle’s verdict


​ Castle provides code samples that allow you to deploy the Castle risk engine into your edge solution.

For more information about why you might want to deploy Castle both at the edge and in-app, see the blog post A Layered Approach to Bot Detection and ATO prevention.

JavaScript code samples are available for Cloudflare and for AWS CloudFront/Lambda@Edge. If you are using another edge/CDN solution, you should be able to modify the code samples to fit your needs.

This diagram shows a high-level overview of how Castle works at each layer.

a diagram showing the flow of request data with a Castle Edge integration
Castle at the Edge


Step 1. Set up edge listeners

Set up Castle at the edge to listen for requests on endpoints typically targeted by attackers: /register, /login, /password-reset.

Step 2. Capture request tokens

Requests to Castle must contain a request token, which is generated by Castle’s JavaScript or Mobile SDK’s. This value can be sent from the front end to the edge as a cookie, header, or form field - the implementation is left to you. See our tutorials on client-side integration for details.

Step 3. Send Castle API requests

Once a valid Castle request token is present in requests at the edge, and the relevant endpoints have listeners set up, send requests to the Castle API every time one of your watched endpoints receives a request.

Step 4. React to the Castle verdict

When a request arrives at one of the integrated endpoints, the sample code will send the context of the request to Castle, and get a recommended verdict (and risk score) in return. If the recommended verdict is “deny”, then you can reject the request at the edge, without the request ever hitting your application. If the recommended verdict is “allow”, then you can allow the request to proceed to your application for further processing.