For developers

The core request/response shapes for integrating against the Inzinx API. This covers the flow most integrations need — submit a rule, activate it, then evaluate or rate. New to this? Start with Getting started.

Authentication

Every request (other than admin-only ones you won't need as a subscriber) carries an x-api-key header — the per-tenant key you got when your workspace was created, sent only over TLS to a rate-limited, per-tenant isolated endpoint (see our security page for the details). Two things determine what a key can do, independently of each other:

Key type — admin keys can submit drafts and activate them, in addition to evaluating and rating; consumer keys can only evaluate, rate, and list — a write to a /tenant/... route with a consumer key returns 403.
Key management — a separate flag, can_manage_keys, controls whether a key can mint or revoke further keys for your tenant. Handing out a regular admin key to a teammate doesn't also give them the ability to create or revoke credentials.

Core endpoints

POST/tenant/rules

Auth: Tenant key (admin)

Submits (or replaces) a draft eligibility rule. Re-submitting the same id is how you edit a draft — it's an upsert, not an append.

{
  "id": "adult-eligibility",
  "conditions": [{ "field": "age", "op": ">=", "value": 18 }],
  "output": { "eligible": true }
}

conditions is a list of condition shapes (implicit AND across the list): a plain leaf { "field", "op", "value" } (op is one of == != >= > <= <, or in against a JSON array — { "field": "state", "op": "in", "value": ["CA","NY","TX"] }), or a group — { "all": [...] }, { "any": [...] }, { "not": {...} } — or a reference to another rule's conditions, { "ref": "other-rule-id" }, for building new rules out of existing ones without duplicating logic. output is any JSON, returned only when every condition passes.

POST/tenant/rules/activate

Auth: Tenant key (admin)

Validates and promotes drafts to active. An empty or omitted body activates every current draft (rules, rating rules, and tables together); pass an optional body to activate only specific ones:

{
  "rule_ids": ["adult-eligibility"],
  "rating_rule_ids": [],
  "table_names": []
}

Activation validates the entire resulting active set as one atomic operation — it either fully succeeds, or nothing is changed. A named id with no matching draft is rejected and commits nothing.

POST/eligibility/{rule_id}/evaluate

Auth: Tenant key (any)

Evaluates an active eligibility rule against arbitrary JSON input. Optional query params: as_of (YYYY-MM-DD, defaults to today) and region.

curl -X POST https://api.inzinx.com/eligibility/adult-eligibility/evaluate \
  -H "x-api-key: <your_key>" -H "Content-Type: application/json" \
  -d '{"age": 25}'

Response:

{
  "passed": true,
  "output": { "eligible": true },
  "trace": [
    { "type": "leaf", "field": "age", "op": ">=", "value": 18, "actual": 25, "passed": true }
  ]
}

trace explains exactly how the result was reached, step by step — including nested all/any/not groups and ref nodes (whose own referenced-rule trace appears as children, not flattened away).

POST/rating/{rule_id}/rate

Auth: Tenant key (any)

Rates a single item against an active rating rule — runs a base rate through an ordered list of factors (table lookups, tiers, deductible curves, conditions, flat adjustments) and returns the computed amount plus a step-by-step trace of how it got there. Same as_of/region query params as evaluate.

curl -X POST https://api.inzinx.com/rating/simple-rating/rate \
  -H "x-api-key: <your_key>" -H "Content-Type: application/json" \
  -d '{}'

Response:

{
  "amount": 525.00,
  "trace": [
    { "step": "base_rate", "amount": 500 },
    { "step": "service_fee", "op": "add", "delta": 25, "amount": 525 }
  ]
}

Beyond this page

This covers the flow most integrations need. The same API also has endpoints for rating rules and rate tables, key management (/tenant/keys...), multi-item bundle and multi-entity rating, and selective deactivation — all reachable the same way, with your own x-api-key. Rating rules also support a few factor kinds that aren't in the drag-and-drop builder yet — composing another rating rule (rating_ref), a raw scripted expression (expr), persistent cross-call state like a deductible paid-to-date (accumulator), and excess-of-loss reinsurance layers — fully usable via this API today. See your dashboard's "Rules & rating guide" (under Advanced, API-only capabilities) for the exact JSON shape of each. If something isn't covered here, ask us.