Introduction

QI Tech's Insurance-as-a-Service lets partners distribute insurance products through an API: browsing the catalog of enabled products, quoting, selling (an order with the insured person's acceptance and payment), tracking the issued policies and following the financial payout of commissions.

This documentation describes the flows, endpoints and data structures of the full insurance distribution journey.

Note: if you have questions at any step of the process, contact api@qitech.com.br describing your problem/question and we will assist you.

Journey overview

1. Catalog — browse the insurance products your integration is enabled to distribute, with their coverages, limits and your commission band (Product Catalog).
2. Quote — price a selection of products and coverages for a customer, without creating any resource (Create quote), and discover the sellable price range of each product (Simulate price range).
3. Order — submit the sale, together with the acceptance you collected from the insured person. The order starts awaiting the payment of the first installment; once payment is confirmed, the order is emitted (Orders).
4. Policies — emitting the order creates one policy per product sold, issued with the insurer. Retrieve and cancel policies individually (Policies). Surface not published yet.
5. Financial — track your commission balance, the statement of movements and the payouts executed (Financial). Surface not published yet.

Every relevant step notifies your callback URL through order webhooks and policy webhooks.

Environments (Hosts)

Insurance-as-a-Service has two environments, SANDBOX and PRODUCTION. Both behave identically, but the SANDBOX environment operates with entirely fictitious amounts and issuances, while Production performs valid transactions and issuances.

Environment	Host
Sandbox	https://api.sandbox.insurance.qitech.app
Production	https://api.insurance.qitech.app

Important notice!

Never use real personal or company data in QI Tech Sandbox environments.

API conventions

• Paths are versioned with the version segment leading the path (e.g. /v1/insurance/order, /v1/product_catalog/products).
• Every resource is addressed by public UUID keys (order_key, policy_key, product_key), never by internal numeric identifiers.
• Collection paths are not always plural: order creation and listing live at /v1/insurance/order (singular), while the key-addressed routes use /v1/insurance/orders/{order_key}. Follow the path stated on each endpoint's own page.
• Monetary amounts travel as JSON numbers with 2 decimal places (e.g. 312.48, never a string), always in BRL and always gross (IOF-inclusive). Rates and percentages are numbers with 4 places in (0, 1] (e.g. 0.1000). Numeric identifiers with significant leading zeros (documents, class codes) remain strings.
• Statuses are lowercase enumerator strings (e.g. awaiting_payment, emitted). Do not map the set as closed — see the reserved statuses.
• Terms are nested objects term: { "start_date", "end_date" } — per product and per coverage.
• Dates follow YYYY-MM-DD and timestamps follow ISO 8601 (2026-07-16T14:03:22Z).
• Listings use offset pagination, but the shape varies per surface — always check the endpoint's own page. Orders use page / page_size (default 50, maximum 200) and return { items, page, page_size, total }; the product catalog uses page / rows_per_page (default 50) and returns { data, pagination { current_page, next_page, rows_per_page } }, with no total.
• Every error (non-2xx) returns the standard body { "title", "description", "translation", "code" }. The code is the only field for programmatic handling — title/description/translation may change without notice.
• Access is always scoped to your integration: a key belonging to another partner is indistinguishable from a nonexistent key and returns 404.

Getting started

Authentication follows the QI Tech signed-request standard, the same one used across the other product lines. See Authentication.