Ruby CAPTCHA Integration

The following tutorial will guide you on how to integrate the TrustCaptcha CAPTCHA solution into your Ruby backend to retrieve and evaluate the CAPTCHA verification result.

require 'trustcaptcha/trust_captcha'

trust_captcha = TrustCaptcha.new('<your_api_key>')
result = trust_captcha.get_verification_result('<verification_token_from_the_client>')
if !result.verification_passed || result.score > 0.5
  # possibly an automated request
end

For custom timeouts, a proxy, or a custom API host see configured usage below.

You should have already completed the following steps before you start with CAPTCHA validation in your Ruby backend.

1. Read the basic Information: For a basic overview, please read the get started guide. We also recommend that you familiarize yourself with the technical concept of TrustCaptcha.

2. Existing CAPTCHA: If you don’t have a CAPTCHA yet, sign in or create a new user account. Then create a new CAPTCHA.

3. A frontend with TrustCaptcha: Integrate the TrustCaptcha widget into your frontend. Go to the CAPTCHA widget guide.

4. Existing Ruby project: You need a Ruby project in which you want to integrate TrustCaptcha.

5. Verification token: You need the verification token from your frontend, which you receive every time you successfully solve the CAPTCHA.

Follow the three steps below to retrieve and evaluate the CAPTCHA verification result in your Ruby backend.

You can find the source code of our Ruby CAPTCHA integration on Github.

To use the TrustCaptcha Ruby library, you first need to add the corresponding dependencies to your project.

gem install trustcaptcha -v '~> 3.0'

You can find our TrustCaptcha Ruby package on Rubygems.

In the next step, retrieve the CAPTCHA result from our servers.

If the CAPTCHA widget has been successfully solved in the frontend, you will receive a so-called verification token. Send this to your backend. You will also need an api-key. You can manage your API keys in the dashboard of your CAPTCHA.

Use the TrustCaptcha class of our Ruby integration to retrieve the verification result from our servers. For the simple case use the static shortcut shown right below; for advanced configuration (custom API host, timeouts, proxy) use the builder/constructor variant further down on this page.

# Retrieving the verification result
begin
  trust_captcha = TrustCaptcha.new('<your_api_key>')
  verification_result = trust_captcha.get_verification_result(verification_token)
rescue StandardError => e
  # Fetch verification result failed - handle error
  puts "Failed to fetch verification result: #{e.class} - #{e.message}"
  status 500
  return { error: 'Captcha verification failed', message: e.message }.to_json
end

Once you have successfully fetched the verification result, you can plan your next steps based on it. A concrete overview of all the information contained in the verification result and their respective meanings can be found in the result validation overview.

# Act on the verification result
if !verification_result.verification_passed || verification_result.score > 0.5
  puts 'Verification failed or bot score > 0.5 – possible automated request.'
end

If you need more control — a different API host, custom timeouts, or a proxy — pass keyword arguments to the constructor.

require 'trustcaptcha/trust_captcha'

trust_captcha = TrustCaptcha.new(
  '<your_api_key>',
  api_host: 'https://api.trustcomponent.com',
  connect_timeout_s: 3,
  read_timeout_s: 5,
  proxy: 'http://myProxyUser:myProxyPassword@proxy.example.com:8080',
)

result = trust_captcha.get_verification_result('<verification_token_from_the_client>')

A constructed TrustCaptcha instance is immutable and safe to share: build it once at startup and reuse it for all requests.

Our service runs in a high-availability setup, so outages are rare in practice. If you want maximum availability — even for the unlikely case where our service is unreachable — you can decide upfront how your backend should react, so your forms and processes don’t block during such an event. Read the Failover behavior page first — it covers the concept, the required widget-side opt-in, the operational checklist, and how to filter failover-derived results in high-security flows.

Once you’ve decided on a policy, the library raises two typed exceptions that both extend TrustCaptcha::FailoverException:

• TrustCaptcha::ServerUnreachableException — high-trust (your backend cannot reach our servers). For example: allow the request and log the incident.
• TrustCaptcha::ClientReportedServerUnreachableException (HTTP 412) — low-trust (the widget claimed a failover, but the backend reaches us fine). For example: reject or soft-challenge.

begin
  result = trust_captcha.get_verification_result(token)
  # Handle the result as you normally would (verification_passed, score, your own policy).
rescue TrustCaptcha::ServerUnreachableException => e
  # Example: our servers are unreachable. Allow + log.
rescue TrustCaptcha::ClientReportedServerUnreachableException => e
  # Example: widget claimed an outage but the backend reaches us. Reject or soft-challenge.
end

When the result cannot be retrieved successfully the library raises a typed exception.

The following example shows a possible implementation of TrustCaptcha in a Ruby backend.

In this example: When a POST request is sent to /api/example, the CAPTCHA verification token is sent to the Ruby backend in the request body. In the backend, our library is used to retrieve the CAPTCHA verification result from our servers and evaluate it. If the verification fails or the bot score exceeds 0.5, a warning is displayed. In addition, the entire verification result is returned to the client.

Hint: The steps and thresholds shown are examples and should be adapted to your individual requirements in your specific use case.

The complete example including source code can be found on Github.

require 'sinatra'
require 'json'
require 'sinatra/cross_origin'
require 'trustcaptcha/trust_captcha'

set :port, 8080
set :bind, '0.0.0.0'

configure do
  enable :cross_origin
end

options '*' do
  response.headers['Access-Control-Allow-Origin'] = '*'
  response.headers['Access-Control-Allow-Methods'] = 'GET, POST, PUT, PATCH, DELETE, OPTIONS'
  response.headers['Access-Control-Allow-Headers'] = 'Content-Type, Authorization, X-Requested-With, Origin, Accept'
  200
end

post '/api/example' do
  content_type :json
  response.headers['Access-Control-Allow-Origin'] = '*'
  verification_token = JSON.parse(request.body.read)['verificationToken']

  # Retrieving the verification result
  begin
    trust_captcha = TrustCaptcha.new('<your_api_key>')
    verification_result = trust_captcha.get_verification_result(verification_token)
  rescue StandardError => e
    # Fetch verification result failed - handle error
    puts "Failed to fetch verification result: #{e.class} - #{e.message}"
    status 500
    return { error: 'Captcha verification failed', message: e.message }.to_json
  end

  # Act on the verification result
  if !verification_result.verification_passed || verification_result.score > 0.5
    puts 'Verification failed or bot score > 0.5 – possible automated request.'
  end

  verification_result.to_json
end

Once you have integrated the TrustCaptcha widget into your frontend and the CAPTCHA result validation into your backend, you can use TrustCaptcha to its full extent. However, we still recommend the following additional technical and organizational measures:

• Security rules: You can find many security settings for your CAPTCHA in the CAPTCHA settings. These include, for example, authorized websites, CAPTCHA bypass for specific IP addresses, bypass keys, IP based blocking, geoblocking, individual difficulty and duration of the CAPTCHA, and much more. Learn more about the security rules.

• Privacy & GDPR compliance: Include a passage in your privacy policy that refers to the use of TrustCaptcha. We also recommend that you enter into a data processing agreement with us to stay GDPR-compliant. Learn more about data protection.

• Accessibility & UX: Customize TrustCaptcha to your website so that your website is as accessible as possible and offers the best possible user experience. More about accessibility.

• Failover behavior: Decide how your backend should behave when our service is temporarily unreachable. This is particularly important for high-availability flows where blocking real users during an outage is worse than letting through a small amount of unverified traffic. Learn more about failover behavior.

• Testing: If you use automated testing, make sure that the CAPTCHA does not block it. Learn more about testing.