Getting started

Quote and issue your account's products from your own systems. Every request is authenticated with an API key, runs in sandbox or production depending on the key, and always uses the published version of each product.

API keys

There are two kinds of key and each one belongs to an environment: live (production) or test (sandbox). The full key is shown only once when created; store it somewhere safe.

Key	What it is for	Where to create it
`sk_live_…` / `sk_test_…`	Server-to-server integrations. Depending on its scopes it quotes, issues, reads quotes and policies, resolves conditions, downloads documents, reports usage or administers the account. Never expose it in a browser.	In your account dashboard, API keys section.
`pk_live_…` / `pk_test_…`	Widget on public websites (scope `quote`). It quotes; issues only its own quotes, each with the single-use `emissionToken` the quote returns (valid for 30 minutes); uploads attachments, resolves dynamic fields and opens signed embed sessions. A payment's status is polled with its `statusToken`. It cannot read quotes, policies or any other account data.	In your account dashboard, API keys section (Publishable type).
Intermediary `pk_…`	Publishable key bound to an intermediary: quotes as them (their view and commission tier) and attributes the operation.	Created by the insurer for each intermediary, or by the intermediary from their portal.

Secret key scopes

Scope	Allows
`quote`	Quote (`POST /api/quotes`), upload attachments (`POST /api/attachments`) and read quotes and their documents (`GET /api/quotes`, `GET /api/quotes/{id}`, `GET /api/quotes/{id}/documents`).
`emit`	Issue policies (`POST /api/policies`) and act on them: resolve conditions, record the insurer's policy number, report usage and regenerate documents. Includes reading policies and their documents.
`read`	Read-only: quotes, policies and their documents (list, get, download and render PDFs).
`admin`	Full access: everything above plus the account administration API (products, shared resources, document templates, payment credentials, API keys and users).

admin includes every scope. A key can combine several, for example quote + emit to quote and issue.
A request without the required scope answers 403 with an error message that names the missing scope (for example emit or admin).
Create each key with the minimum scopes your integration needs.

A key with the admin scope grants full access to your account: products, payment credentials and key management. Never use it in an integration. The keys created together with the account (Live key and Test key) have the admin scope: to integrate, create new keys with quote, emit or read and keep the admin ones for account administration only.

A revoked key stops working immediately (401).
An intermediary key stops working if the intermediary is deactivated, banned or leaves the organization (403).
Only a hash of the key and its last 4 characters are stored.

Authentication

Send the key in the x-api-key header on every request. The key determines the account (tenant) and the environment: you do not need to send either.

Authentication header

curl https://api.quore.app/api/quotes/QUOTE_ID \
  -H "x-api-key: sk_test_…"

401: missing, invalid or revoked key.
403: the key lacks the required scope, is publishable and the resource is a read, or belongs to an inactive intermediary.

Base URL

https://api.quore.app

The base URL is the same for sandbox and production: the key decides the environment.
Every route lives under /api, for example /api/quotes.
Bodies are JSON (Content-Type: application/json), except attachment uploads (multipart).
Routes and JSON keys are in English; error messages are in Spanish.

Environments and numbering

Every key belongs to an environment: test (sandbox) or live (production). A key only reads and writes records of its own environment.
An id from the other environment answers 404; asking a list for the other environment answers 400.
Sandbox policies are numbered in their own series, TEST-POL-0001, TEST-POL-0002…, never consuming production numbers.
Sandbox payments use each provider's test credentials; never the production ones.
Webhooks are sent in sandbox too: the event environment field tells which one it is.

Request limits

Publishable keys (widget and intermediary keys) are limited per IP and per account. Default values:

Operation	Per IP every 10 min	Per IP per day	Per account per day
Quote (`POST /api/quotes`)	150	1,500	50,000
Issue (`POST /api/policies`)	30	300	10,000
Resolve fields (`POST /api/products/{id}/field-resolve`)	600	6,000	200,000

Above a limit the API answers 429 with a Retry-After header (seconds to wait).
The signed-identity embedded widget is limited per user: 30 issuances every 10 minutes and 300 per day.
Attachment uploads with a publishable key have their own per-IP limit too.
Secret keys do not use these widget limits: they are limited per key at the API gateway, with a generous allowance meant for server-to-server integrations.
Values can be tuned per installation. Always retry with a delay on 429.

Versioning

The API always quotes and issues with the published version of each product. Draft changes do not affect the API until they are published.
Each quote is tied to the version it was priced with, and is issued with that same version even if a newer one is published later.
Each product reference is generated on the fly from the published version: it updates itself when you publish.
API routes carry no version number; changes are made in a compatible way (fields are added, not removed).