# Vercel Functions

Add IronDome disposable email checks to Vercel Functions. Choose the Node.js adapter or portable Edge client and configure server secrets.

## Choose your runtime

Use the Node.js adapter for Vercel Node.js Functions and the portable entry for Vercel Edge Functions. Neither uses the dedicated Deno adapter.

Use the runtime supported by your deployed framework. The Edge example below is for Vercel’s standalone `/api` function format; framework route conventions can differ. See [Vercel runtimes](https://vercel.com/docs/functions/runtimes/edge).

## Install and configure

Install the JavaScript SDK in your project:

```sh
npm install @irondome-dev/sdk@0.2.0
```

Add `IRONDOME_API_KEY` and `IRONDOME_BASE_URL` in your Vercel project's environment variables. Choose the environments that need them and redeploy after changes. Use `https://api.irondome.dev` for every plan. Keep these variables server-only; do not give the key a `NEXT_PUBLIC_` prefix. See [Vercel environment variables](https://vercel.com/docs/environment-variables).

## Node.js functions

Select Node.js 22 or newer. Create one client at module scope in a server-only helper, for example `lib/irondome.js`:

```js
import { IronDome } from '@irondome-dev/sdk/node';

const client = new IronDome({
  apiKey: process.env.IRONDOME_API_KEY,
  baseUrl: process.env.IRONDOME_BASE_URL,
  timeoutMs: 3000,
  maxSockets: 32,
  maxInFlight: 64,
  idleTimeoutMs: 20000,
});

export async function checkSignupEmail(email) {
  return await client.check(email);
}
```

Call this helper from your existing protected signup handler after request validation and rate limiting. In a standalone Vercel project, `/api` functions can use the documented Web Standard `fetch` export; Next.js projects use their framework's server route convention. See [Node.js Functions](https://vercel.com/docs/functions/runtimes/node-js).

The module-scoped client shares its HTTPS pool between requests handled by the same warm instance. Do not call `client.close()` in a request's `finally` block; concurrent invocations may still use it. Cold starts, instance replacement, and expired sockets can still require a new connection. No socket is opened simply by importing the module.

## Edge functions

For an existing standalone Edge function, keep its runtime configuration:

```js
export const config = { runtime: 'edge' };
```

Put the following helper in a server-only module and call it from that function's existing signup handler:

```js
import { IronDome } from '@irondome-dev/sdk';

export async function checkSignupEmail(email) {
  const client = new IronDome({
    apiKey: process.env.IRONDOME_API_KEY,
    baseUrl: process.env.IRONDOME_BASE_URL,
    timeoutMs: 3000,
    maxInFlight: 4,
  });
  return await client.check(email);
}
```

The Edge runtime provides Fetch but does not support the Node HTTPS agent used by `/node`. Let the platform own sockets and pooling. Do not import `/node` or `/deno` into an Edge bundle. The portable client contains no Node imports or runtime dependencies. See [Edge supported APIs](https://vercel.com/docs/functions/runtimes/edge#edge-runtime-supported-apis).

## Signup decisions and warmup

Await the check before creating the account. Reject disposable emails according to your policy, and treat SDK errors separately. Keep the integration inside signup rather than publishing a generic email-check proxy.

An optional `warmup()` uses the same client's transport and consumes no email check. Node.js warm instances can reuse the pool, but later requests may go to another instance. Keep work within your function's supported lifecycle and do not make signup wait for an extra health request. See [performance](/docs/guides/performance).