Customer-hosted APIs for Excel models

From Excel to API, without rewriting the logic.

XSheet turns your workbook’s formulas and lookup tables into a versioned API, without developers having to recreate the calculation logic. Your team maintains the model in Excel. Results are verified and each new version is approved before it goes live.

  • Customer-hosted

    keeps the application, models and APIs in your environment

  • API

    lets your systems call the model

  • Approval

    controls which version serves production requests

  • Evidence

    connects each result to its model version and release history

Use cases

Put the logic your teams maintain in Excel to work.

Pricing is one application. The same workbook-to-API process can serve eligibility rules, commissions and cost calculations. These illustrative examples show where it can fit; each workbook needs a compatibility and results check.

  • Underwriting and eligibility

    An application sends risk details. Rules maintained in Excel return eligibility, limits or a referral flag for a person to review.

  • Product quotes

    A sales application sends a product configuration and quantity. The workbook calculates the quote from cost tables, discounts and margin rules.

  • Commissions

    A sales system sends results for a period. The workbook applies the plan’s tiers and splits, then returns the payout and its calculated components.

  • Cost and savings estimates

    A planning tool sends usage and project assumptions. An Excel model returns estimated costs, savings or payback for the scenario.

Read the insurance and banking guide for rating, underwriting and financial models.

Your infrastructure

Keep the workbook and its API inside your environment.

Run the complete XSheet installation alongside the systems that use your models. Your team controls the infrastructure, access and model-release policy. Publishing a model and calculating with it do not require sending your workbook or request to an XSheet-operated service.

  • Run the complete platform

    The application, model publishing, calculations and stored records run in your installation. Model owners and engineering work with the same versions.

  • Understand every connection

    Keep calculation calls local. Review sign-in, software updates and operational tools separately, including any requirement to work without internet access.

  • Define who operates what

    Your team operates the environment; XSheet supplies the software. Agree responsibility for recovery, maintenance and support before production use.

From workbook to production

Keep your workbook and production logic together.

When business logic lives in both a workbook and application code, every change has to be carried across and checked again. XSheet serves the workbook’s own logic and governs the resulting service.

  • Maintain the formulas in one place

    Change the factors, formulas or lookup tables in the workbook and upload a new version. Engineering integrates with its API instead of maintaining another copy of the calculation logic.

  • Check the effect of a model change

    Compare XSheet’s results with the values Excel saved, then run the service’s test cases on the proposed change. Portfolio impact analysis is planned. Approvers can review the calculation evidence before a new version takes over.

  • Give calling systems a defined contract

    Named workbook inputs and outputs become typed API fields. Your business applications call the service. When a version changes that interface, the promotion review flags added, removed or retyped fields.

  • Trace a result to its model

    Follow a request ID to the version behind the result. Review who changed the model and who approved its release. While the inputs are retained, replay the call bit for bit.

Workbook to API

How a workbook becomes a service your systems can call.

The workbook defines the calculation. XSheet builds and verifies the service; your engineering team connects the systems that need its results. Excel does not run when the API answers a request.

  1. 01

    Define the inputs and outputs

    Name the workbook inputs in_* and the outputs out_*, then upload it. XSheet uses those names for the API fields, reports unsupported formulas by cell and turns a supported model into a fixed version.

  2. 02

    Verify against Excel

    The service is checked against the values Excel itself calculated and saved in the workbook, and every mismatch is reported down to the cell. Test runs can then compare the new version with results recorded from the one it replaces.

  3. 03

    Approve and connect

    After review and approval, the version serves production calls. Your systems send the model inputs and receive the calculated results, together with the version and request ID.

auto-rating v12

Production

Request

JSON
POST /v1/evaluate/auto-rating

{
  "inputs": {
    "State": "WY",
    "VehicleAge": 4
  }
}

Workbook

auto-rating.xlsx
Named cells in the auto-rating workbook
NameCellValue
in_StateInputs!C4WY
in_VehicleAgeInputs!C54
out_FinalPremiumRating!F181,284.50

Response

200 OK
{
  "request_id": "req_01j9x4…",
  "service": "auto-rating",
  "environment": "production",
  "version": { "number": 12 },
  "outputs": {
    "FinalPremium": 1284.5
  }
}
Fictional insurance example: the caller sends State and VehicleAge, XSheet calculates FinalPremium, and the response identifies the version used. Field names omit the workbook’s in_ and out_ prefixes.

Technical and commercial evaluation

Review the parts your team will own.

A calculation service has to fit your release process, application architecture and operating requirements. Use these questions to scope an evaluation with the people responsible for each.

  • Business and model owners

    Will the API reproduce our workbook, and what will change for the people using its results? Check supported formulas, compare expected outputs and review the effect of a model change before approval.

  • CTOs and enterprise architects

    Where does business logic live, and how does it fit our application estate? Review the workbook-to-API boundary and the complete installation your team can operate in its own environment.

  • Engineering leadership

    What must our applications send, and how will we handle a model change? Review the generated contract, validation errors, version information and measured calculation times.

  • CISOs and security architects

    What can an uploaded workbook access, and who can change production? Review isolation, identity, API-key scopes and the controls around calculation data.

  • Procurement

    What would demonstrate a fit before we commit? Agree a representative workbook, expected results, traffic and deployment scope, along with the operating and support responsibilities to be assessed.

  • Vendor risk management

    Which records and dependencies can we examine? Review model-change approvals, audit records, release provenance and data handling against your assessment requirements.

Before you evaluate

Questions about your workbook and the systems around it.

What changes in the workbook before it becomes an API?
The model author names the input cells or ranges with in_ and the outputs with out_. These names define the API fields. XSheet checks the formulas, reports unsupported features with their cell references and turns a supported workbook into an immutable version.
Does Excel have to run for each API call?
No. Excel remains the authoring tool and a source of expected results for verification. XSheet answers each API call itself, isolated from the rest of the platform. Your application sends the model inputs and receives the calculated outputs.
What does our engineering team still need to do?
Your team connects the calling systems to the API, maps their data to the named inputs and handles responses and errors. Each service has a typed OpenAPI contract. Formula changes become workbook versions; changes to the input or output contract are flagged for review before promotion.
How do we check the API results?
XSheet checks its results against the values Excel saved in the workbook, to 15 significant digits, and reports differences at cell level. Test runs compare a proposed version with results recorded from the current one; portfolio impact analysis is planned. Your evaluation should include representative inputs and expected results from your own workbook.
Who decides when a model change goes live?
By default, the author requests promotion and a second person with a releasing role approves the exact change. Production rejects direct edits, including administrator edits. An emergency switch-off also requires two people.
Can we trace a past result to the model that produced it?
Each call has a request ID, and each recorded call has a receipt identifying the workbook version and the exact build behind the result. A call can be replayed bit for bit while its inputs are retained. The audit log records changes and approvals.
Can our team run the complete installation?
Yes. The customer-hosted model includes the application, model publishing, calculation APIs and persistent data. The calculation path does not need an XSheet-operated service. Identity, updates and operational tools have separate connectivity requirements; fully air-gapped deployment needs its own validation.

XSheet

See how your model would work as an API.

Discuss the workbook your team maintains and the applications that need its results. Explore integration and deployment in your environment.