Build on iqava

1. Create your workspace — sign in and complete onboarding.
2. Choose your edition— Insurer, Reinsurer, Insurance broker, Reinsurance broker or Service provider. The provisioning engine applies that edition's blueprint.
3. Invite your team — add users and assign roles under Administration, or connect SSO and let people join automatically.
4. Pin your services — keep your most-used modules on the home tab.

Create your workspace

Editions are blueprints, not forks. Your onboarding answers select a blueprint that the provisioning engine applies in one transaction — services, default roles with permission scopes, your admin account and the initial audit trail. The console then renders only the services your edition is entitled to.

Every workspace gets its own address — your-company.iqava.com— chosen when you create it. It's where your whole team signs in, and you can share it directly with new staff.

• Pick it at sign-up — onboarding suggests an address from your organization name and checks availability live.
• Isolated sign-in — a session is valid only on the workspace it was opened on, so signing in to one workspace never grants access to another.
• Find it any time — your address is shown under Administration → Organization Settings; the sign-in page also has a “go to your workspace” box.

Prefer your own domain (e.g. erp.acme.com)? Administrators can connect one under Administration → Identity & SSO → Custom workspace domain: verify ownership with a DNS TXT record, point it to us with a CNAME, and we provision the HTTPS certificate. White-label domains are available on enterprise plans — talk to us.

One platform spans the whole value chain. Each module is tenant-scoped, permission-gated and audited; your edition decides which are switched on.

Access is governed by granular resource:action permissions bundled into roles with data scopes (own → global). Connect Microsoft Entra or Google SSO, claim your domains, enable just-in-time provisioning and map directory groups to roles. Provision users either by pull (directory sync) or push (SCIM 2.0). Every change is written to an immutable audit trail, and tenant isolation is enforced at the database with Postgres row-level security.

Read the security overview

iqava's AI is grounded on your live workspace data and disciplined by design: the deterministic system does the routine work, AI does the unstructured bits, and anything that moves money, binds risk or sends external communications stays behind a human approval gate. Every AI action is audited and scoped to your tenant.

• Claims-Triage Assistant — on any claim, get a coverage assessment, a suggested reserve range, recommended next actions and a draft acknowledgment. A proposal only.
• Reconciliation Assistant — proposes likely matches (direct, bank-charge and one-to-many summation) for unmatched bank and cashbook lines.
• No-code automation — triggers → conditions → actions for the repeatable work, with deterministic reliability.
• MCP server — connect iqava to Claude or any compatible agent as a remote Model Context Protocol server. Generate a per-workspace token under Administration → Identity & SSO → AI agent access (MCP); calls are tenant-scoped and audited.

Integrate iqava with your systems over a versioned REST API. Generate a key under Administration → Identity & SSO → API keys (scoped read or read+write), then authenticate with a bearer header. Every call is isolated to your workspace by row-level security and audited.

curl https://your-workspace.iqava.com/api/v1/claims \
  -H "Authorization: Bearer iqk_your_key_here"

Endpoints (v1)

• GET /api/v1/me — verify a key and see its workspace
• GET /api/v1/claims · GET /api/v1/claims/{id} · POST /api/v1/claims (write)
• GET /api/v1/policies · GET /api/v1/policies/{id}
• GET /api/v1/accounts

Lists support ?q=, ?limit= and ?offset=. Responses are JSON ({ data, count, limit, offset }); errors are { error: { status, message } }.

Webhooks

Register endpoints under Administration → Identity & SSO → Webhooks and subscribe to events (policy.bound, claim.registered, claim.settled). Deliveries are POSTed as { event, data, timestamp }, signed with X-Iqava-Signature: sha256=<HMAC> (verify with your signing secret), and retried automatically on failure.

Official SDK

import { IqavaClient } from "@iqava/sdk";

const iqava = new IqavaClient({
  baseUrl: "https://acme.iqava.com",
  apiKey: "iqk_…",
});
const { data } = await iqava.listClaims({ q: "fire", limit: 20 });

Administrators can connect their organization's own domains under Administration → Identity & SSO. Both require a quick DNS step, and neither takes effect until verified:

• SSO domains— claim a domain so SSO users with that email domain route to your workspace (with optional just-in-time provisioning). To prevent anyone claiming a domain they don't own, you publish a TXT record (iqava-verification=…) and click Verify. Only verified domains route SSO or JIT.
• Branded email — send verification, password-reset and notification emails from your own domain (e.g. [email protected]). Add a sending subdomain and publish the SPF/DKIM records we generate; until verified, emails use the platform sender, so deliverability is never at risk.

Work where your team already does. iqava brings the workspace straight into the Office apps — permission-scoped to your workspace and written to the audit trail, exactly like the web console.

Installing them

• Org-wide (recommended). Your Microsoft 365 administrator adds them once in Microsoft 365 Admin Center → Settings → Integrated apps → Upload custom apps, using the manifest URL. The iqava button then appears in Outlook/Excel for the people you choose — nothing for them to search or install.
• Just for you. In Outlook or Excel, open Get Add-ins → My Add-ins → Add a custom add-in → Add from URL and paste the manifest.

Manifest URLs: /outlook-manifest.xml, /excel-manifest.xml and /word-manifest.xml (under https://iqava.com). A one-click install from the Microsoft AppSource store is coming. Need help rolling these out?

Run iqava inside your own environment — the same platform as our cloud. The self-host stack brings up PostgreSQL, applies database migrations and seed data, then starts the calculation service and the console as one Docker Compose unit. A Helm chart is included for Kubernetes. This guide takes you from nothing to a running instance.

1. What you need

• A machine to run it on — any OS with Docker: Linux, Windows or macOS. ~2 vCPU and 4 GB RAM is plenty to start. A Linux server is recommended for production, but not required.
• Docker + Docker Compose v2 — the only hard requirement. On Windows/macOS install Docker Desktop; on Linux install Docker Engine. (docker --version should print v2+.)
• OpenSSL (or Node) — to generate one secret. Pre-installed on most systems.
• For production: a domain name and a reverse proxy for HTTPS — Caddy, Nginx or Traefik. Caddy is the simplest (automatic TLS).
• Optional integrations: a Groq (or Anthropic) API key for AI; any S3-compatible bucket (AWS S3, Cloudflare R2, MinIO) for file storage; a Resend key for email; Microsoft Entra/Google OAuth apps for SSO. All optional — iqava runs fully without them.

Tools & resources (links)

• Docker Desktop (Windows/macOS)
• Docker Engine (Linux)
• Docker Compose
• Caddy (easy HTTPS reverse proxy)
• Nginx
• Helm (Kubernetes)
• kubectl
• Groq Console (AI keys)
• Cloudflare R2
• AWS S3
• MinIO (self-host storage)
• Resend (email)
• Microsoft Entra admin
• Google Cloud Console (OAuth)
• PostgreSQL

2. Get it running

1. Get the code into a folder on your machine — clone from your iqava repository (the Git URL provided with your license, or your own private mirror), then enter it:

   git clone <your-iqava-repo-url> iqava cd iqava

2. Create your config from the template and set the one required secret:

   cp .env.selfhost.example .env # put the output of this into AUTH_SECRET in .env: openssl rand -base64 33

   Also change POSTGRES_PASSWORD for production. Every other value has a sensible default.
3. Bring up the whole stack:

   docker compose -f docker-compose.selfhost.yml up -d --build

   Compose starts PostgreSQL, runs a one-shot job that applies the schema and seeds the permission catalog, then starts the calc service and the console.
4. Open http://localhost:3000(or your server's address), sign in with the developer email sign-in (on by default), and create your first workspace.

Clarification — single-tenant. A self-hosted instance is normally for one organization, so the developer email sign-in gets you started immediately. For multiple internal orgs, each still gets its own workspace.

3. Put it on a domain with HTTPS

For production, run a reverse proxy in front of the console (port 3000) to terminate TLS, and point AUTH_URL and APP_URL in .envat your HTTPS domain. With Caddy it's two lines:

iqava.yourcompany.com {reverse_proxy localhost:3000}

Then set AUTH_DEV_LOGIN=false once you've enabled SSO or password sign-in, and re-run the compose up -d.

4. Turn on optional integrations

Set the relevant variables in .env, then re-run docker compose -f docker-compose.selfhost.yml up -d:

• AI assistants — GROQ_API_KEY (leave AI_MODEL empty for the default).
• File storage — STORAGE_ENDPOINT/REGION/BUCKET/ACCESS_KEY/SECRET_KEY for any S3-compatible bucket.
• Email — EMAIL_PROVIDER=resend, RESEND_API_KEY, EMAIL_FROM.
• SSO — the AUTH_MICROSOFT_ENTRA_ID_* / AUTH_GOOGLE_* credentials; buttons appear automatically.
• Operator console — PLATFORM_ADMINS (comma-separated emails) to reach /platform.

5. Backups & upgrades

• Backup the database (the only stateful piece):

  docker exec iqava-postgres pg_dump -U iqava iqava > iqava-backup.sql

• Upgrade — pull the latest code and rebuild; the migrate job applies any new migrations automatically:

  git pull docker compose -f docker-compose.selfhost.yml up -d --build

• Kubernetes — use the Helm chart in deploy/helm/iqava (console, calc, postgres, ingress and a migration job).

6. Troubleshooting

• View logs: docker compose -f docker-compose.selfhost.yml logs -f console.
• Console won't start & complains about AUTH_SECRET — set it in .env and re-run up -d.
• A feature shows “not configured” — that integration's env vars aren't set yet (see step 4). The rest of the app still works.
• Reset everything (deletes data): docker compose -f docker-compose.selfhost.yml down -v.

Stuck?The assistant in the bottom-right corner can walk you through any of these steps — ask it things like “how do I enable storage” or “the migrate job failed.” Or talk to our team about a managed private deployment.