# Deno

Check disposable emails in Deno with the IronDome SDK. Configure network permissions, protect your API key and reuse a native HTTP client.

## Native Deno or portable Fetch

Use the native Deno adapter when your runtime exposes `Deno.createHttpClient`. It owns an HTTP client with HTTP/1.1 and HTTP/2 enabled, connection reuse, and explicit shutdown. In a restricted hosted runtime, use the portable Fetch entry instead. For Supabase, follow the [Supabase guide](/docs/guides/supabase).

Import the pinned [JavaScript SDK from npm](https://www.npmjs.com/package/@irondome-dev/sdk). The native adapter is `npm:@irondome-dev/sdk@0.2.0/deno`; the portable Fetch entry is `npm:@irondome-dev/sdk@0.2.0`.

## Run a script

Set `IRONDOME_API_KEY` in an ignored `.env` file. Save this as `check-email.js`:

```js
import { IronDome } from 'npm:@irondome-dev/sdk@0.2.0/deno';

const client = new IronDome({
  apiKey: Deno.env.get('IRONDOME_API_KEY'),
  baseUrl: 'https://api.irondome.dev',
  timeoutMs: 3000,
  idleTimeoutMs: 20000,
  maxIdleConnections: 8,
});

try {
  const result = await client.check('person@example.com');
  console.log({ valid: result.valid, disposable: result.disposable });
} finally {
  client.close();
}
```

Grant only the required environment and API network access:

```sh
deno run --env-file=.env --allow-env=IRONDOME_API_KEY --allow-net=api.irondome.dev check-email.js
```

The API host stays `api.irondome.dev` for every plan. Avoid logging emails or credentials.

## Long-running functions and servers

Create one native client for the lifetime of a Deno server or warm function instance. Await the check inside your existing signup handler before creating the account. Do not close the shared client after an individual request; close it only when requests have drained at final shutdown.

The short script above closes its client because its work is complete. An always-running server has a different lifecycle. Recreate the client when its credentials or endpoint change.

## Pool settings

| Option | Default | Purpose |
| --- | --- | --- |
| `timeoutMs` | `5000` | Deadline for a check |
| `idleTimeoutMs` | `20000` | Idle pool timeout in milliseconds |
| `maxIdleConnections` | `8` | Maximum idle connections per host |
| `caCerts` | System trust | Optional additional trusted PEM certificates |

The native adapter maps the idle settings to Deno's `poolIdleTimeout` and `poolMaxIdlePerHost`. System TLS trust remains enabled. The server or platform may close connections earlier; HTTP/2 negotiation is not a guarantee that every request uses HTTP/2. See [Deno's official HTTP client API](https://docs.deno.com/api/deno/fetch/).

## Restricted runtimes

If `Deno.createHttpClient` is unavailable, import `npm:@irondome-dev/sdk@0.2.0` and omit native pool options. The portable entry uses platform Fetch; it does not own the sockets or expose native pool controls.

Deno can resolve pinned `npm:` imports for the portable package or its `/deno` entry. Use only a published version, not an unpinned development import. See [Deno npm support](https://docs.deno.com/runtime/fundamentals/node/).

## Warmup and errors

`await client.warmup()` can prepare the same native transport before email checks without using check credits. Use it ahead of user submission, not before every check. It cannot prevent platform cold starts or guarantee a later serverless invocation uses the same client.

API, transport, and timeout errors remain errors; do not convert them into an allowed-email result or blindly retry a request that may already have counted. See [errors](/docs/errors) and [signup validation](/docs/guides/signup).