Skip to main content
Most Korint endpoints are synchronous: the response tells you the outcome. A few are not, and they are concentrated exactly where a new-business integration spends its time — signature, payment, document processing, and activation. Completion happens elsewhere: a customer signs in their browser, Stripe confirms a mandate, a scheduled job reaches a start date. There are no outbound webhooks today — the webhooks in the platform are inbound, Stripe and the signature provider notifying us. Tell us if your integration needs them.

​
What is synchronous

These return the outcome, and you can act on the response directly:
  • Creating and editing customers, policies and assets.
  • POST /policies/{policyId}/calculate-quote and POST /policies/{policyId}/quote — pricing is computed during the request. A price that cannot be produced fails the call or is recorded as a quote failure; it does not arrive later.
  • POST /policies/{policyId}/confirm — validation is immediate.
  • Registry lookups: GET /siren, GET /vehicle-information/*, GET /address-autocomplete/suggest. These need an actor with the right permissions — GET /siren is refused to an anonymous session (403), so a public funnel collects a typed SIRET and lets enrichment happen server-side on the PATCH instead.
Products whose pricing the carrier keeps — rather than delegating it to a Korint pricing engine — are the exception. Their quote depends on an external response, so treat it as a step whose result you re-read rather than one you assume.

​
What you have to observe

​
Signature

POST /policies/{policyId}/signature creates the request and returns the signers with their links. It does not wait for anyone to sign. Poll the signature requests for the policy:
Response
This endpoint returns 200 with an empty signatureRequests array when nothing matches — an empty list is not an error and not a “not yet created” signal you can distinguish from a bad id. Confirm you are passing the policy id as externalId.
The policy itself also moves as signing completes, so GET /policies/{policyId} is the better signal for “may I proceed?”, and the signature requests are the better signal for “who still has to sign?”. A signer who has lost the email needs a fresh nudge rather than a new request: POST /signature/{signatureId}/policy/{policyId}/signers/{signerCustomerId}/resend, or fetch their link again with the matching /link endpoint. Signature is a human action: expect minutes to days.

​
A payment method after the browser setup

Confirming a SetupIntent happens between the customer’s browser and Stripe. We learn about it from Stripe’s webhook, so the payment method appears on our side shortly after — not at the moment the browser reports success. Read GET /customers/{customerId}/payment-methods until the method appears. If it never does, the setup did not actually succeed; re-check the browser-side result rather than retrying the secret.

​
Documents

POST /policies/{policyId}/documents returns an upload URL; you then upload the file to that URL directly. The document exists once that upload finishes, but nothing has looked at it yet. Processing is a call you make, and it is the exception to this page: GET /documents/validate?key=… scans, classifies and extracts, streaming progress as Server-Sent Events. Consume the stream instead of polling. Settled results live on GET /policies/{policyId}/documents/validity and GET /policies/{policyId}/document-extractions. Fields configured with autoFill are populated from a successful extraction (see Read the product configuration), so re-read the entity rather than assuming your earlier values survived.

​
Coming into force

Activation is driven by time and by payment, not by your call. A signed contract comes into force when its start date arrives, and — on products with requireFirstPaymentToActivate — once the first premium has been collected. GET /policies/{policyId} carries the state. A future-dated contract sits signed-but-not-in-force until its start date.

​
Renewals, repricing and recurring billing

These are driven by scheduled jobs on our side, on the product’s own cycle. Nothing is triggered by an API call you make, and nothing notifies you. Read the current state when you need it — a renewal appears as a new branch on the policy.

​
Two things worth knowing

Re-read the entity, not your own copy. Document extraction and registry enrichment both overwrite values you sent, so working from what you posted is how an integration drifts out of step with the contract. And re-reading is not the same as re-issuing: calling the original endpoint again may create a second signature request or a second setup. Rate limits. There is no published rate limit on the endpoints in this guide. A few endpoints are individually limited and say so in the reference — starting an anonymous session and the claim lookup routes are each capped at 100 per hour. Treat the absence of a limit elsewhere as a courtesy rather than a guarantee.