Best approach for handling email verification links in Rails API with React frontend setup

Frontend
1

I’m working with a Rails API backend and a React frontend app. My Rails app sends out verification emails with confirmation links.

I’m trying to figure out the best way to handle these email links. Should they go straight to the backend API or load the frontend first?

Here are the two options I’m considering:

Option A - Direct backend hit
Email link goes to api.mysite.com/verify/:token which processes the request and redirects to app.mysite.com/verification/success or /error

Option B - Frontend first
Email link opens app.mysite.com/verify/:token which then makes an AJAX call to the backend API

Which approach do you use in your projects?

For option A, I’ve set up a basic controller to handle redirects:

namespace :email_handlers do
  resources :verifications
end

namespace :app_routes do
  app_url = Rails.configuration.app_domain
  
  scope app_url do
    resources :verifications, only: [] do
      get 'success'
      get 'error'
    end
  end
end

And my verification controller looks like:

class EmailHandlers::VerificationsController
  def show
    service = VerifyTokenService.new(token: params[:token])
    if service.process
      redirect_to(
        app_success_verification_url,
        user_email: service.user.email
      )
    else
      redirect_to(app_error_verification_url)
    end
  end
end

I’m having trouble with the URL helpers when pointing to different domains. What’s the right way to handle cross-domain redirects here? Also, what HTTP status codes should I use for success vs failure redirects?

Both approaches seem to need a lot of coordination between frontend and backend so I want to make sure I pick the right one.

2

honestly, option A is way cleaner. I’ve tried both approaches and frontend-first just adds unnecessary complexity. for cross-domain redirects, hardcode the frontend URLs in your controller instead of using helpers - something like redirect_to "https://app.mysite.com/verification/success?email=#{service.user.email}". use 302 for both success and error since they’re temporary redirects.

3

nice setup! why’d you go with Rails API + React instead of Turbo? also curious about token expiration - what happens when users click old verification links? one UX thing to consider: with option A, users might see a quick flash of your backend domain before the redirect.

4

I’d go with option B. Option A looks easier at first, but it’s not worth it. With option B, users stay on your frontend the whole time - better UX and consistent branding. They won’t see weird backend URLs or deal with redirect delays. Plus you get way more control over error handling and loading states. You can show proper loading spinners while verification runs, and handle different errors with actual helpful messages instead of those generic redirect pages nobody likes. For implementation: set up your React route to hit the verification endpoint right when the component mounts, then update the UI based on what comes back. This scales much better when you want to add stuff like auto-login after verification or onboarding flows. The frontend/backend coordination isn’t bad if you handle errors properly and keep your API responses consistent.