Skip to content
Telesurety
Platform · 07 · APIPartly live

The same capabilities, inside your own software.

Document reading, coverage comparison and insurer connectivity, available through an API without leaving the software you use.

Request a demo

Highlights

Partner integrations
Live
A quote and policy API connected to a dealer network and a dealer lead intake hub run in production today.
Insurer connections
14
Insurers connected through web services. Partner flows use some of them; the general API is being designed to let your own software use these connections.
General API
Roadmap
Document reading, multi-insurer quotes and coverage comparison for agencies and agency software vendors.

Telesurety's integration layer already runs connected to corporate partners' systems. A dealer network's ERP sends quote and policy requests to this API and gets the results back from it, and dealer leads reach the call center through a single intake point. The general API for agencies and agency software vendors is on the roadmap.

How it works

A quote and policy API for corporate partners is live in a dealer network today. A general API for intermediaries and software vendors is on the roadmap.

  1. 01 / 05

    The ERP sends a request

    The corporate partner's ERP sends a proposal request to the API. The API records it, e-mails the responsible staff and raises a notification in the operations panel.

  2. 02 / 05

    Quotes are collected in parallel

    The automatic quoting engine requests motor liability and motor own-damage quotes from the connected insurers at the same time. Each insurer call runs in its own isolated scope, so one insurer's failure does not affect the others' results.

  3. 03 / 05

    Vehicle codes are mapped

    The partner's make, model and package codes are translated to the industry's standard vehicle code catalog through a mapping table. When staff upload the vehicle's e-invoice PDF, the model is also identified from the invoice.

  4. 04 / 05

    The policy is issued

    In the operations panel, staff review the quotes and issue the policy through the insurers' web services. In one partner flow, issuance starts automatically for motor liability requests that meet agreed rules; if the insurer's amount exceeds the partner's amount, issuance waits for staff approval.

  5. 05 / 05

    The result returns to the ERP

    Staff submit the policy result from the operations panel, and the API writes it to the partner's ERP. Nobody re-enters it on the dealer side.

  6. Illustrative. Names and values shown are examples. Step by step. The ERP sends a request, Quotes are collected in parallel, Vehicle codes are mapped, The policy is issued, The result returns to the ERP.

Corporate partner API

Live

Quotes and policies across a dealer network, ERP to ERP.

The request comes from the ERP and the result goes back to it. The automatic quoting engine and the operations panel do the work in between. The flow is built for everyday risks such as restarts, failed attempts and unauthorized access.

  • Durable job queue: automatic quote jobs are stored in the database. After a restart, open jobs are picked up again, and a recovery loop re-queues unfinished work at regular intervals.
  • Controlled retries: a failed automatic issuance attempt is retried after a wait that grows exponentially. Every issued policy appears in the staff operations queue.
  • Dealer-level isolation: each staff user sees only the records of dealers assigned to them, and another dealer's record behaves as if it does not exist. Tests that run multi-dealer scenarios on a real database protect this rule.
  • Hardened security: repeated failed logins are rate-limited, credentials in raw insurer requests and responses are masked in API output, values are escaped before they go into insurer requests, and standard browser security headers are set. Any endpoint without an explicit authorization rule fails the tests.
  • Operational reporting: a renewal radar that sorts policies into overdue and upcoming expiry windows, policy penetration reports, and performance and management briefing PDFs. Each report is limited to the dealers the user may see.

Dealer lead intake hub

Live

Leads enter through one door and reach the call center intact.

Dealer systems send customer, vehicle, branch and insurance-type data to an authenticated intake endpoint. There the data is normalized, validated and forwarded asynchronously to the call center's CRM. The call outcome comes back to the hub through a separate authenticated endpoint.

  • Intake validation: ID and tax number format, phone, birth date (future dates are rejected) and the province code in the plate are checked. A lead that arrives again with the same partner reference number is recognized and reported as a duplicate.
  • Beyond motor: insurance types such as earthquake and home are accepted. For these types the vehicle fields are optional.
  • Transactional outbox: the incoming record and the message to be sent are saved together in one database transaction, so no lead is lost in transit. An undelivered message is retried at growing intervals and moves to a dead-letter state when attempts run out. Each destination has its own queue.
  • Call outcome feedback: the call result, assigned agent, number of contacts and last call time are written back to the hub. The latest outcome for each lead is visible there.
  • Management dashboard: lead analysis with daily trends, call outcomes and customer and policy penetration by dealer, a staff performance ranking, a data-quality page listing entries to fix, a policies view, manual entry for leads from outside sources, and a motor liability quote run directly from the hub.

General API

Roadmap

Document reading, quotes and comparison from your own software.

The general API planned for agencies that keep their own software and for agency software vendors will do the same work as the platform's workspace, with no separate business logic. The platform is being designed API-first: every client, the workspace included, will connect to the platform only through the API.

  • Document reading: each field in the submitted document will come back with a confidence score and its location on the page. Fields that fail validation or fall below the confidence threshold will be marked as awaiting approval.
  • Multi-insurer quotes and comparison: one request will get quotes from connected insurers, and coverages will be laid side by side in the common coverage language. Premiums will always come from the insurer's response.
  • Contract first: each module will have a code-reviewed OpenAPI contract, and client libraries will be generated from it. The major version will sit in the URL, an old version will be kept through a transition period, and deprecation will be announced in standard headers.
  • Predictable behavior: errors will use the standard problem-details format, record-creating requests will accept an idempotency key, lists will use cursor paging, and personal data will never go into URLs.
  • Event notifications: webhooks will notify the agency's own system. Each will carry a unique key so the receiver can discard duplicates. Webhooks are not part of the first platform release.

Use cases

From an intermediary's day.

  • 01

    A quote for a car sold at the dealer

    A car is sold at the dealership and the partner's ERP sends a proposal request. While you work on something else, the vehicle code is mapped and motor liability and own-damage quotes are collected from connected insurers. When you open the panel the quotes are ready to compare; once you issue the chosen policy and submit the result, it is written to the dealer's ERP record.

  • 02

    Shared lead follow-up with the call center

    Own-damage, motor liability, earthquake and home leads from dealers arrive in the hub, and a lead sent again with the same reference is set aside as a duplicate. The call center makes the calls, and the outcome and agent details flow back to the hub. In the management meeting you see from one dashboard which dealer's leads turned into policies and which entries need fixing.

  • 03

    An agency on its own software (roadmap)

    Your agency wants to keep the software it already uses. Once the general API is available, your software will send a registration photo, the fields will come back with confidence scores, and your team will approve any uncertain field. The same record will request quotes from connected insurers in one call, and the results will come back side by side in the common coverage language.

Planned endpoints

  • Document reading

    Send a document; get fields, confidence scores and locations back.

  • Multi-insurer quotes

    Get quotes from connected insurers with one request.

  • Coverage comparison

    Compare quotes in the common coverage language.

  • Event notifications

    Notifications for fields awaiting review or completed jobs.

What AI does · What you decide

What AI does

The API does exactly what the platform does; there is no separate business logic.

What you decide

Human review applies to the API too: uncertain fields come back marked as awaiting approval.

Details

Technical details

Live today
Corporate partner quote and policy API; dealer lead intake hub with call center CRM connection.
Partly live
The operations panel has a versioned integration API with a published OpenAPI description. A mobile backend authenticated by service token uses it for customers, policies, quote requests, claim requests and documents; the customer app built on it is at pilot stage.
Lines
Partner API: motor liability and motor own-damage. Lead hub: motor plus non-vehicle types such as earthquake and home.
Insurer connections
Our existing insurer connection layer reaches the web services of 14 insurers. Quotes, policy import and document retrieval run through these connections; partner flows use some of these insurers.
Data isolation
Today, dealer-level authorization in the partner API. In the general API, agency identity will come from the access token, isolation will be enforced at the database level, and insurer credentials will be kept in an encrypted vault.
Roadmap
General API, event notifications (webhooks), channel and partner gateway. The first platform release will run against a simulated insurer provider instead of real insurer connections.

Questions

Frequently asked questions

Can I use the general API today?

Not yet. What runs in production today are integrations built for corporate partners. The first release of the general API will run against a simulated insurer provider instead of real insurers, and the real document-reading model will follow later through our research work. If you want an early look at the scope, we can talk it through in a demo call.

Can AI take an irreversible action through the API?

No. In the general API, AI cannot start binding actions such as issuing, cancelling, endorsing a policy or opening a claim; the model suggests the form and the user starts the action. The model cannot call an insurer and never produces a premium, which always comes from the insurer's response. The automatic motor liability issuance in today's partner flow uses no AI: it follows rules agreed with that partner, and every record appears in the operations queue.

What happens when an insurer's service fails?

In today's flows insurer calls run at the same time, and one insurer's failure does not affect the others' results. Unfinished jobs are picked up again from the durable queue, and undelivered messages are retried at growing intervals. The rules planned for the general API sort errors into temporary, permanent and credential errors. Credential errors are never retried, so repeated failed logins do not lock an agency's insurer account. Waits will include random jitter, and a circuit breaker per insurer is planned. Policy issuance is never blindly retried: the insurer is asked for the status first, and an unclear result goes to a person.

Can we connect our dealer or partner system?

Taking a request and writing the result back already runs today in live integrations built for specific partners. A channel and partner gateway module that generalizes this is planned: it will take requests from dealer and partner systems, write results back to them and offer an embeddable quote widget. The module is scheduled after the first platform release.

How will the API be priced?

Per-transaction pricing is planned for the general API. Quotes, policy imports and document reads will be counted separately; each count will be written in the same database transaction as the work itself, and a retried operation will not be counted again. The pricing model will be validated with agencies.

Other parts

Back to platform