---
title: "Resolve emails to accounts"
method: POST
path: "/accounts/resolve"
tags: ["accounts"]
---

# Resolve emails to accounts

`POST /accounts/resolve`

## Request

- Base URL: `https://api.instruxi.dev/api/v1/enforcer`
- URL: `https://api.instruxi.dev/api/v1/enforcer/accounts/resolve`
- Auth: one of:
  - API key in header `Authorization`
  - API key in header `X-API-Key`

Resolves many email addresses to account ids within ONE tenant, case-insensitively, in a single query — the read an importer runs BEFORE it writes anything, so the operator can see and fix unmatched rows while nothing has happened yet. Read-only and idempotent. Every input line comes back with a verdict in the order it was sent, with the email echoed exactly as supplied so a caller can line the answer up against its own file: `found` (with account_id and active) or `not_found`. An account that exists but is inactive is still `found` — whether that disqualifies it is the caller's policy. An email belonging to ANOTHER tenant comes back not_found, exactly like one that exists nowhere: the tenant is the whole boundary. Cross-tenant callers MUST pass tenant_id; tenant-scoped callers may pass their own or omit it. At most 1000 emails per call.

## Request body

- InternalDeliveryHttpHandlerResolveEmailsRequest
  - `emails` string[]
  - `tenant_id` string: TenantID scopes the lookup. Required for a cross-tenant caller, optional (and only their own) for everybody else — the same rule the fuzzy search follows, and for the same reason it exists there.

## Response `200`

OK

- InternalDeliveryHttpHandlerResolveEmailsResponse
  - `data` InternalDeliveryHttpHandlerResolveEmailsResult
    - `found` integer
    - `not_found` integer
    - `results` InternalDeliveryHttpHandlerResolvedEmail[]
      - `account_id` string
      - `active` boolean
      - `email` string: Email is echoed EXACTLY as sent, not normalised, so the caller can line the answer up against its own file without matching on a value this service rewrote.
      - `status` string: Status: found | not_found. An account that exists but is INACTIVE is still `found` — whether that matters is the caller's policy, and `active` is there to decide it with.
    - `tenant_id` string: TenantID names the tenant that was actually searched. The console runs one deployment per environment where the TENANT is the environment, so "which tenant answered" is not a detail.
  - `success` boolean

## Other responses

- `400`: Bad Request
- `401`: Unauthorized
- `403`: Forbidden

---

[API](https://skmtc.dev/instruxi/apis/enforcer-api.md) · [All operations](https://skmtc.dev/instruxi/apis/enforcer-api/llms.txt) · [OpenAPI document](https://skmtc.dev/instruxi/apis/enforcer-api/revisions/fa82bc1becc0?raw)