Build your own app on Rewardata

Power apps you build with Google AI Studio, Lovable, Base44, Bolt, v0, Replit, Cursor or any AI app builder using the Rewardata REST API or hosted MCP server — standardised pay, tax, social-security, benefits, cost-of-living and global-mobility data for 200+ countries, one consistent interface.

Quick start

  1. Get an API key

    Sign in and copy your key from your profile. Keys look like rwd_… and are issued to approved accounts. Send it in the X-API-Key header on every /data call. (The catalogue endpoints — /countries, /fields, /categories — are public and need no key.)

  2. Call the REST API

    Base URL https://rewardata.com/api/v1. Full reference at /docs.

    # Pay/tax/COLA data for one country + field
    curl "https://rewardata.com/api/v1/data?country=DEU&field=average_annual_wage" \
         -H "X-API-Key: rwd_your_key_here"
    
    # Global-mobility net-to-net (keep an employee whole when relocating)
    curl -X POST "https://rewardata.com/api/v1/mobility/net-to-net" \
         -H "X-API-Key: rwd_your_key_here" -H "Content-Type: application/json" \
         -d '{"home_country":"USA","host_country":"DEU","household":"family_of_4","gross_salary":200000}'
  3. Or connect the MCP server

    For AI agents and builders that speak Model Context Protocol (Claude, Cursor, ChatGPT, agent frameworks), point the client at https://www.rewardata.com/mcp with your API key — the model can then query the data as tools, no glue code.

    {
      "mcpServers": {
        "rewardata": {
          "url": "https://www.rewardata.com/mcp",
          "headers": { "Authorization": "Bearer rwd_your_key_here" }
        }
      }
    }

    "X-API-Key" is accepted here too — same key, either header.

🔒 Keep your app private to your own users

AI app builders publish a public website by default. Two things follow, and both matter: your API key must never reach the browser, and you decide who can use the app.

✗ Don't put your key in the front-end

If the Rewardata key is in client-side code (a React component, a "fetch" the browser runs, an exposed env var), anyone who opens your site can read it from the network tab and use your quota. Builders that "call the API from the app" do exactly this.

✓ Hold the key server-side + require login

Keep the key as a secret in a backend / edge function. Your browser app calls your backend; the backend adds the key and calls Rewardata. Then gate the app with your own authentication so only your signed-in users get through.

The pattern

Your users (browser)  ──►  Your app + login  ──►  Your backend / edge function
   (holds REWARDATA_API_KEY secret)
  ──►  Rewardata API
                ▲ only authenticated users               ▲ key never leaves the server

A minimal server-side proxy (works in Supabase / Vercel / Netlify / Base44 functions)

// SERVER-SIDE ONLY — never bundled into the browser.
// The browser calls this (e.g. /api/rewardata), not Rewardata directly.
export default async function handler(req, res) {
  // 1) Require YOUR app's login — only your authenticated users pass.
  const user = await getSessionUser(req);          // Supabase / Clerk / Firebase / Base44 auth
  if (!user) return res.status(401).json({ error: "Sign in required" });

  // 2) Call Rewardata with the secret key (from an env var, never shipped to the client).
  const r = await fetch(
    `https://rewardata.com/api/v1/data?country=${req.query.country}&field=${req.query.field}`,
    { headers: { "X-API-Key": process.env.REWARDATA_API_KEY } }
  );
  res.status(r.status).json(await r.json());
}
  • Store the key as a secret (env var / secrets manager), not in the repo or front-end.
  • Turn on the builder's auth and require login before the app loads.
  • Set the deployment to private / members-only where the builder supports it.
  • Optional: have your backend pass an end-user id so you can rate-limit per user.

By app builder

In every case the rule is the same — the key lives server-side, the app sits behind your own login. Here's the tool-specific way to do it. (Steps reflect each tool's standard features; check the linked docs for the latest.)

AI app builders (prompt-to-app)

Google AI Studio / Gemini

AI-Studio apps run in the browser, so don't paste the key into client code. Put it in a Google Cloud Function / Cloud Run (or Apps Script) that proxies the call, and have the app hit that. Gate access with Google sign-in.

AI Studio ↗ · Docs ↗

Lovable

Lovable pairs with Supabase. Store the key as a Supabase Edge Function secret, call Rewardata from that function, and read the result in your app. Use Supabase Auth so only your users get in.

Lovable ↗ · Docs ↗

Base44

Call Rewardata from a Base44 backend function, keeping the key in its server-side secrets (never in the page). Base44 has built-in user accounts — set the app private so it's members-only.

Base44 ↗ · Docs ↗

Bolt.new

Bolt scaffolds a full-stack app (often Next/Vite + Supabase). Call Rewardata from a server route / edge function with the key in an environment variable, and add login (Supabase / Clerk) before you deploy.

Bolt ↗

Vercel v0

v0 generates Next.js. Call Rewardata from a Route Handler or Server Action with the key in a Vercel Environment Variable, and protect it with NextAuth / Clerk (plus Vercel deployment protection).

v0 ↗

Replit (Agent)

Put the key in Replit Secrets (available only to server code) and call Rewardata from the backend, never the client. Add Replit Auth to require sign-in.

Replit ↗

Databutton

Databutton apps have a Python backend and a secrets store — keep the key there, call Rewardata from a backend endpoint, and return only the results to the UI. Use its built-in auth to restrict access.

Databutton ↗

No-code & internal-tool builders

Retool

Add Rewardata as a REST API resource (base URL + the X-API-Key header in the resource config). Retool runs queries server-side, so the key never reaches the browser. Restrict the app with Retool permissions / SSO.

Retool ↗

Bubble

Define the Rewardata call in the API Connector with the key, and run it from a backend workflow (server-side) so the key stays private. Control access with Bubble user accounts + privacy rules.

Bubble ↗

FlutterFlow

FlutterFlow API calls run on the client, so route them through a Cloud Function that holds the key and returns the data. Gate the app with Firebase Auth.

FlutterFlow ↗

Glide

Glide is client-side — keep the key out of it. Call Rewardata from a serverless function (or Make / Zapier webhook) that holds the key, and have Glide call that. Limit the app to signed-in users (row owners / email allowlist).

Glide ↗

Softr

Softr is a front-end over your data — connect Rewardata through a backend automation (Make / Zapier / n8n) or your own proxy that holds the key, then surface the results. Use Softr user groups + gated pages.

Softr ↗

AI coding IDEs & agents

Cursor / Windsurf

You're writing the code, so put the key in a server-side env var (.env, git-ignored), call Rewardata from a backend route, and add your chosen auth. For personal/internal use you can also connect the MCP directly.

Cursor ↗ · Windsurf ↗

Claude / ChatGPT

Connect the MCP with your own key (or OAuth) for personal/internal use — it stays with you. Don't embed a shared key in a published app this way.

Claude ↗ · ChatGPT ↗

Design & site builders

Framer

Framer publishes a public site, so call Rewardata from a serverless proxy (Vercel / Netlify function) that holds the key, fetched by a Framer code component. Gate it with Framer gated content / membership.

Framer ↗

Webflow

Use Webflow Cloud / a serverless function (or your own) to hold the key and call Rewardata — not client-side JS. Restrict access with Webflow Memberships.

Webflow ↗

Any other builder

Same rule: key in a server-side secret, requests proxied through your backend, app behind your login. If the browser can read the key, so can everyone.