Skip to content
Telesurety
Platform · 01 · Connector HubPartly live

One connection to 14 insurers.

Instead of logging into each insurer's portal, the platform carries quote and policy operations to the insurers' web services through one common contract and writes the result to the record.

Request a demo

Highlights

Insurers connected via web services
14
In the operations panel. Most connections run against the insurers' production services; for a few, the move to production is still under way.
Parallel quoting and policy records
Live
One request reaches the selected insurers at once. A priced quote becomes a policy record in the agency's register in one step.
Multi-tenant Connector Hub
Prototype
Runs on a simulation provider today. Moving the real insurer connections in is on the roadmap.

Connector Hub puts the insurers' very different web services behind one shared layer. In the operations panel, connections to 14 insurers run through this layer today: quoting, plus quote documents and policy import where the insurer offers them. The next step is to move that layer into a multi-tenant hub where each agency connects with its own code and credentials.

How it works

Web service connections to 14 insurers are live in the operations panel today. Moving them into a single multi-tenant Connector Hub is on the roadmap.

  1. 01 / 05

    Enter the request once

    Enter the customer, the insured asset, the branch and the coverage you want in one form. Before anything is sent, the form shows which insurer will be asked for which branch.

  2. 02 / 05

    Insurers are called in parallel

    The request goes to all selected insurers at the same time. Each insurer is called in its own scope with a time limit. A slow or failing insurer does not hold up the rest.

  3. 03 / 05

    Responses are normalized

    Payment options from different insurers land in one list with number of installments, total premium and installment amount. Coverage lines show the value the insurer applied.

  4. 04 / 05

    Compare and open the document

    Review the quotes side by side. Where the insurer offers it, open the insurer's own quote PDF from the result screen.

  5. 05 / 05

    Turn it into a policy record

    The chosen quote becomes a policy record in one step. Customer, asset, insurer, branch and premium carry over without retyping; you add the start date, policy number and payment details.

  6. Illustrative. Names and values shown are examples. Step by step. Enter the request once, Insurers are called in parallel, Responses are normalized, Compare and open the document, Turn it into a policy record.

Live · Operations panel

Live

Only the insurer sets the price

The panel connects to the web services of 14 insurers through one shared provider layer. Each insurer's own request and response format is handled in that layer. Staff work with a single form and a single result list.

  • An insurer with incomplete service settings, no provider, or no offer for the branch is not called. No price is invented; staff see the reason in a plain sentence.
  • When an insurer gives only the number of installments and the total premium, the installment amount is calculated by splitting the total evenly. When an insurer reports no payment plan, the quote's own premium is shown and no single-payment line is invented.
  • For coverage such as an İMM limit or replacement-car days, the requested value is matched to the first option on the insurer's own fixed scale that is not lower than the request. If no option is high enough, the highest one applies.
  • Foreign-resident health quotes can be run in bulk from an Excel list. Each row is priced as its own quote run, and bulk lists run in a separate queue so they do not hold up single quotes on screen.
  • Before insurer requests and responses reach the logs or the technical detail view, the panel masks the password, username, API key, ID number and tax number fields it recognizes.

Partly live · From quote to policy

Partly live

Quotes become records, policies are read from the insurer

A priced quote becomes a policy record in the agency's register without re-entering data. Policies held at insurers can be pulled in read-only. Issuing the policy directly through an insurer's web service exists today only in narrow cases.

  • If the price has expired or the quote run was cancelled, the panel blocks the conversion. A run can produce only a single policy.
  • For a branch the policy register does not cover yet, the panel does not convert the quote; the policy is entered by hand on the Policies screen.
  • Policy import, where the insurer offers it, brings approved policies and endorsement rows for the date range you pick. Each insurer has its own maximum range.
  • Imported rows are never written to the database and are cleared when you leave the page. ID numbers are shown masked.
  • Insurer-side issuance is limited today to two narrow cases: automatic traffic-policy issuance with a specific insurer in a separate channel built for a corporate partner, and a card-payment purchase flow with a specific insurer in the customer app. The purchase flow runs in the test environment only.

Prototype · Multi-tenant Connector Hub

Prototype

Each agency on its own code and contract

In the new platform, Connector Hub is being built as a separate hub where each agency connects to insurers with its own agency code and credentials. Today the prototype runs only on a simulation provider and does not connect to any real insurer. Moving the real insurer connections in is on the roadmap.

  • The simulation provider covers all 14 insurers for traffic and kasko, makes no network calls and always returns the same price for the same request. It reproduces delays, timeouts, rejections, missing data, credential rejection, installments and coverage scales based on real insurer behavior. The result screen carries a visible SIMULATION badge.
  • Quote runs are durable. The request returns immediately while the work is stored in the database, so it survives restarts and can be shared across several workers. Agencies take fair turns in the queue, and resending with the same idempotency key returns the same run.
  • Errors are split into transient, permanent and credential errors. A transient error is retried a limited number of times with exponential, randomized backoff, and only when the connection never opened or the call creates no record at the insurer. Credential errors are not retried, and the connection is marked invalid.
  • Each insurer has its own circuit breaker. A burst of consecutive transient errors pauses calls to that insurer for a short time and returns 'insurer service not responding' at once. Credential errors do not trip it.
  • Credentials are kept in a vault with AES-GCM envelope encryption and a data key per agency. An encrypted record copied to another agency cannot be decrypted, secrets cannot be read back through the API, and every decryption is audit-logged. Moving the master key into a key management service outside the app server and database is on the roadmap.
  • Each insurer call is counted once, in the same database transaction as its result. The platform never uses an agency code of its own and never shares credentials between agencies; with real connections, quotes, policies and commission will be created under the agency's own contract with the insurer.

Use cases

From an intermediary's day.

  • 01

    One round for a motor renewal

    A customer's kasko is up for renewal. Staff enter the vehicle and the coverage wanted, such as the İMM limit and replacement-car days, once. The form shows in advance which insurers will be asked, and an insurer that answers slowly does not hold up the list. The result shows each insurer's installment options and applied coverage values side by side. Staff open the insurer's own quote PDF where offered and share it with the customer.

  • 02

    Foreign-resident health for a corporate client

    A corporate client asks for health cover for its foreign employees living in Türkiye and sends the staff list as an Excel file. Staff upload the list; every row is checked first, so the list is never half-processed when a row has an error. Each row is priced as its own quote run, and the results are reviewed row by row.

  • 03

    Month-end register check

    An operations lead pulls approved policies and endorsement rows for a date range from an insurer that offers policy import, then checks them against the agency's register. The list stays on screen only, ID numbers are masked, and it is gone once the page is closed.

What it does

  • Live

    One request, many quotes

    A request reaches connected insurers at once; responses land in one list.

  • Live

    Policy import

    Issued policies are pulled from the insurer and linked to the record.

  • Live

    Document retrieval

    Policy and quote documents are fetched and attached to the record.

  • Roadmap

    Cancellations and endorsements

    Cancellation and endorsement operations under the same contract for every insurer.

  • Roadmap

    Multi-tenant connection hub

    Connector Hub as a separate platform, where each intermediary connects with its own code and authorization.

What AI does · What you decide

What AI does

Reads coverage and document content in insurer responses and prepares it for comparison.

What you decide

What goes to which insurer follows rules and your choice. Each intermediary connects with its own agency code and authorization.

Details

Technical details

Branches priced via web services
Trafik, Kasko, TSS (complementary health), Seyahat (travel), Yabancı sağlık (foreign-resident health). Support differs per insurer.
Live today
Parallel quoting, quote-to-policy record, bulk foreign-resident health quotes; read-only policy import and insurer quote PDFs where the insurer offers them
In the prototype (simulation)
Multi-tenant credential vault, connection test, error classes with limited retries, per-insurer circuit breaker, durable quote runs, one count per insurer call
Roadmap
Moving real insurer connections into the Hub, a key management service for the master key, issuance, cancellation and endorsement through the Hub, admin notification on credential errors
Data handling
Recognized password, username, API key, ID number and tax number fields are masked before logging. Imported policy lists are never written to the database.
Verification
The connection layer is checked by automated tests against simulated insurer responses, without calling real services.

Questions

Frequently asked questions

Is Connector Hub live today?

Part of it is. The shared layer in the operations panel handles quoting with 14 insurers, plus quote documents and policy import where the insurer offers them. The multi-tenant hub is a prototype in the new platform and runs on simulation only. The existing connection code will be moved into the Hub in waves: each insurer is first verified with an agency using it in real work, then switched on per agency with a feature flag. Rolling back means turning the flag off.

Does the panel issue the policy at the insurer?

Only in narrow cases today. The panel's issue step records the policy in the agency's register, and staff enter the policy number. There is no insurer connection code for cancellation or endorsement yet; the Hub only reserves an interface slot for them. When issuance or cancellation times out in the Hub, there will be no blind retry: the insurer is first asked for the status using the platform's reference, and if it offers no such query, the result is marked uncertain and handed to a person.

What happens when an insurer is slow or returns an error?

The other insurers' quotes still come in, because each insurer is called separately with a time limit. A late insurer's row shows a timeout. The prototype Hub also reports an insurer's approval requirement and missing data as separate results. Credential errors are never retried, so the agency's insurer account does not get locked by repeated failed logins. Notifying the agency admin on a credential error is on the roadmap.

Does AI decide what goes to which insurer?

No. Insurer connections follow fixed rules. AI never estimates a price; premium, coverage and installments come only from the insurer's response. Under the platform's design rules, for binding steps such as issuing, cancelling or endorsing a policy, a model can at most suggest the form, and a person starts the action.

How will I know a connection works?

In the operations panel, an insurer with incomplete settings is flagged on the quote form with its reason before you send. In the prototype Hub, each insurer credential has a 'test connection' check; it creates no quote and is not counted as a transaction. The connections screen shows each connection's status (not configured, untested, active, invalid) and its last successful use. For real insurers, the test is planned to call an insurer endpoint that creates no quote.

Other parts

Back to platform