Skip to main content
Updates to live policies is a common need of insurance policy management. You can configure your product to change behavior depending on the information you need to update:
  • if the information is not necessary for documents or quotes, such as a customer’s email, you can modify it directly on the dashboard;
  • if the information is pricing or contractual, such as coverage level, you must create a mid term agreement.

​
Mid term agreements (MTA)

Korint uses the same branch system as for signing new business, so the process of your MTA is very similar.
  • You can create as many MTA projects as you want: your entities will reset to the CREATED status on that MTA project.
  • Once you’re happy with one of the quote options, you can lock it in and your policy becomes QUOTED.
  • Once you have filled in additional non pricing information, you can confirm your policy: it becomes CONFIRMED and you can send your MTA documents to your policy holder for signature.
  • Once the policy holder signs the MTA, it immediately becomes live and all other MTA projects are abandoned.
When you create a MTA project, you will already have all information pre-filled from the current policy, so you only need to modify what is necessary. If you try to modify information that is not necessary for quotes or documents, you will get an error when quoting that prompts you to modify the information directly instead of using a MTA.

​
Driving an MTA through the API

An MTA is a branch, so the calls are the new-business calls pointed at a new branch. Every one of them carries the branch id, including the signature request — omit it anywhere and the call acts on the live contract instead, which is the single most common way an MTA integration fails.
1

Open the MTA branch

branchType is required. The branch comes back pre-filled from the live contract; keep its id.A contract can only take an MTA from certain statuses: POLICY_CONFIRMED, POLICY_SIGNED or POLICY_STARTED. A contract that is still POLICY_CREATED or POLICY_QUOTED has no live terms to adjust, and one that is POLICY_SUSPENDED or POLICY_STOPPED can no longer be adjusted at all.Opening an MTA on an ineligible contract is refused with CONFLICTING_POLICY_STATUS, whose policyStatus lists the statuses that would have allowed it.
2

Change what needs changing

PATCH /policies/{policyId}, PATCH /assets/{assetId} and PATCH /customers/{customerId}, each with ?branchId=<mta branch>.Two attributes on each field decide whether it belongs in an MTA, and you need both — see What an MTA can change below. Attempting a FORBIDDEN field is rejected immediately, naming the field and the context.
3

Re-quote, confirm, sign

The signature call needs ?branchId= just as much as the others, even though the parameter is optional in the reference. The documents offered for signature are the ones on the branch you name, so omitting it looks for the MTA’s paperwork on the live contract, finds only the already-signed new-business copy, and fails with:
documentNumber: 0 while GET /policies/{policyId}/documents?branchId=<mta branch> plainly lists the document is the signature of this mistake. No amount of waiting or retrying fixes it — the call is looking at the wrong branch.
MTA documents are generated on the branch a few seconds after the MTA is quoted, so poll GET /policies/{policyId}/documents?branchId=<mta branch> until the signable type appears rather than calling signature immediately after confirm.
4

Abandon a draft you no longer want

POST /policies/{policyId}/branches/{branchId}/invalidate, which requires a reason in the body — BROKER_REQUEST or CUSTOMER_REQUEST for a draft someone decided against. Signing one MTA abandons the others automatically, so you only need this to clean up drafts you are not pursuing.
POST /branches/{branchId}/fork copies a branch up to its quote, which is how you explore a variant of an MTA without losing the work already on it.

​
What an MTA can change

This is the rule to build your form on, and it takes two field attributes, not one: The middle row is the one that costs time, because nothing fails until two calls later. The PATCH succeeds, and then:
An MTA exists to re-price a contract, so it must contain at least one change that affects pricing. A branch whose only edits are requiresOnChange: NOTHING fields has nothing to quote and is refused — which means a form filtered on mtaModification: ALLOWED alone works or fails depending purely on which fields the user happened to touch.
Filter on both attributes when building the form, and check the result is non-empty. Products differ sharply here: across the demo products the number of fields an MTA can re-price ranges from a handful down to one, and a product can plausibly have none — in which case it has no MTA flow at all and you should say so rather than offer a button that cannot work.

​
Listing branches

GET /policies/{policyId}/branches returns every branch on the contract, including merged and closed ones, with mergedAt and closeReason populated. It does not paginate — data always holds the full set. So filter on branchStatus rather than taking the first entry; BRANCH_OPEN is the work in progress. See Which draft is live.

​
Billing Updates

Once you’ve quoted a MTA, the Korint dashboard shows the difference in price between the currently live policy and the proposed MTA, the updated billing plan, and any potential reconciliations if the product is configured for it. Currently you cannot change your billing configuration during a MTA, so if a policy is billed monthly it will remain as such until it ends.

​
Computing the difference over the API

There is no delta field. You compute it from two reads, and the second one is easy to miss — the live premium needs a read with no branchId, because reading with the MTA branch gives you the new premium:
Do not reach for proratedQuote here. It is not the delta: it is the proposed premium apportioned over the remaining period, which answers a different customer question (“what will I be charged now?”). Both numbers belong on an MTA screen, and they are not interchangeable. See What will actually be debited.

​
When the change takes effect

GET /policies/{policyId}/branches/{branchId}/effective-date answers this only for MTAs that move a date — one that adds or replaces an asset, or edits an asset’s start or stop date. For those it returns the earliest such date. An MTA that only changes declared or priced fields has no date of its own to report: the endpoint returns {}, and the change takes effect when the policyholder signs. That is expected, not a malformed request — so treat an empty response as “on signature” rather than displaying an empty field.

​
Blocked Updates

Some updates are currently not supported:
  • Changing the start date of the policy once it has started
  • Planning a MTA to go live at a specific date
The first of those is the policy’s start date. An individual asset’s startedAt is a different thing, and products often declare it mtaModification: ALLOWED — changing it is exactly the kind of MTA that gets an effective date. Read the attribute per field rather than inferring from this list.