Stop Spinning Up a Separate Server: Colocate Your Backend With Expo Router API Routes

Minimal Setup: Getting /api/hello to Respond

Start with the smallest possible thing so you can confirm the path is wired up. Three steps:

1. Create an app/api/ folder
2. Add hello+api.ts inside it
3. Run npx expo start and hit /api/hello

The file is just this:

// app/api/hello+api.ts
export function GET(request: Request) {
  return Response.json({ ok: true, message: "hello from the edge" });
}

Export a function named GET, and it handles GET requests. Export POST, and you handle POST. The return value is a standard Response, so the Response.json() helper works directly.

Once this responds, the path is live. From here it is just a matter of growing that GET into the handler you actually need.

Receiving a RevenueCat Webhook

Now to the real work. RevenueCat POSTs subscription events — initial purchase, renewal, cancellation — to a URL you configure. Your job is to receive them and reflect the change into your own database or logs.

Create app/api/revenuecat+api.ts and write a POST handler.

// app/api/revenuecat+api.ts
export async function POST(request: Request) {
  // 1. Confirm authenticity via the Authorization header RevenueCat sends
  const auth = request.headers.get("authorization");
  if (auth !== `Bearer ${process.env.REVENUECAT_WEBHOOK_SECRET}`) {
    return new Response("unauthorized", { status: 401 });
  }
 
  // 2. Pull out the event body
  const payload = await request.json();
  const event = payload.event;
 
  // 3. Branch by event type
  switch (event.type) {
    case "INITIAL_PURCHASE":
    case "RENEWAL":
      await grantEntitlement(event.app_user_id, event.expiration_at_ms);
      break;
    case "CANCELLATION":
    case "EXPIRATION":
      await revokeEntitlement(event.app_user_id);
      break;
    default:
      // Absorb unhandled events with a 200 so RevenueCat stops retrying
      break;
  }
 
  // 4. Always return 2xx. Return an error and RevenueCat retries forever
  return Response.json({ received: true });
}

The line that matters most is step 4 in the comments. The rule for a webhook receiver is: if you received it, return 2xx. If you return a 500 because your processing failed, the sender assumes delivery failed and keeps retrying, and the same event arrives again and again. Catch database failures with your own queue or logs, and keep the outward response closed at 2xx. Separating those two concerns up front saves you later.

Signature Verification and Where Secrets Belong

The example above only checks the Authorization header, but some providers send an HMAC signature over the request body. In that case, compute the signature against the raw body string and compare it to the header value in constant time.

import { createHmac, timingSafeEqual } from "node:crypto";
 
async function verifySignature(request: Request, secret: string) {
  const raw = await request.text(); // you need the raw body, pre-JSON
  const signature = request.headers.get("x-signature") ?? "";
  const expected = createHmac("sha256", secret).update(raw).digest("hex");
 
  const a = Buffer.from(signature);
  const b = Buffer.from(expected);
  // timingSafeEqual throws on length mismatch, so guard first
  if (a.length !== b.length) return { ok: false, raw };
  return { ok: timingSafeEqual(a, b), raw };
}

The easy thing to miss here is that signature verification needs the raw body before it is parsed as JSON. If you call request.json() first, the body is consumed and the string you need for the calculation is gone. Read the raw string with request.text() and run JSON.parse yourself.

Never put secrets in the repository. Reference them through process.env and register the values in your deployment target's environment variables — eas env:create on EAS Hosting, or the Environment Variables panel on Vercel. Never prefix a server-only secret with EXPO_PUBLIC_. That prefix bakes the value into the client bundle, where anyone who inspects the app can read it.

Deployment Target: EAS Hosting vs. Vercel

To ship an app that includes API Routes, you need hosting that can run a server. Here are the two I have actually used, laid out along the axes that help you decide.

For new apps, I lean toward EAS Hosting. The reason is simple: eas deploy sits in the same CLI lineup as building the app, so there is no context switch. If you already host a frontend on Vercel, align with that instead and you add nothing to manage. This is less about technical superiority than fitting your existing toolbox.

When to Use a Standalone Worker Instead

Colocating is not a cure-all. Here is the rule I actually apply across six apps.

Work whose lifetime matches the app gets colocated. Webhook receivers, auth proxies, aggregations specific to that one app — all of these become useless the moment the app dies, so they belong in the same repo.

Work shared across multiple apps stays standalone. My AdMob SSV verification uses the same logic across all six apps, so it lives in a single independent Worker. Copying that code into each app would mean fixing six places on every change, which flips the benefit of colocating on its head.

So the deciding question is: does this backend share a fate with this app? If yes, colocate. If it is a shared asset, keep it standalone. Drawing that one line made almost all of my hesitation disappear.

Three Things That Tripped Me Up in Production

Finally, three snags the docs do not put in bold. I hope they save the next person some time.

The first is the web.output: "server" setting I mentioned earlier. If it works on your local dev server but the API Routes vanish in a production build, suspect this first. I lost half a day to it.

The second is the order of request.json() and signature verification. Defer a check that needs the raw body, and the body is already consumed by the time you get there. Design for calling request.text() once for verification and parsing yourself from the start.

The third is webhook timeouts. If you synchronously await every database write and external API call, the response lags and the sender may treat it as a timeout. Hand heavy work off asynchronously after receiving, and close the receiver at 2xx immediately. In my setup, response time including cold start dropped from about 300ms to 80ms — roughly 4x faster.

Cutting one server means one fewer thing to monitor and one fewer place to forget. The next time you build a small app and wonder where the webhook receiver should live, I hope this helps you decide. Thank you for reading.