How it works
How an Excel workbook becomes an API.
The model author identifies which values callers will supply and which results they need back. XSheet reads those named cells, prepares the workbook’s formulas for production and creates the API contract. Engineering connects the calling systems; model changes pass through verification and approval before release.
Step 1
Choose the values your systems will send and receive.
Give each input a name that starts with in_ and each result a name that starts with out_. In the API, each field is the name without its prefix, so in_State becomes State.
- A single cell is a value: a number, text, a logical value or empty.
- A range whose first row holds unique column labels is a table: an array of row objects keyed by those labels, such as the locations on a property policy.
- Any other range is a matrix: an array of rows.
A request may send fewer table rows than the range holds, and the rest stay blank. Supported Data Validation rules become part of the input schema. Rules with an enabled Stop alert reject invalid inputs before calculation; advisory rules do not. Custom formulas and unsupported rules produce warnings at upload.
Interface
| Workbook name | API field | Shape |
|---|---|---|
| in_State | State | Value |
| in_Locations | Locations | Table |
| out_FinalPremium | FinalPremium | Value |
Request
{
"inputs": {
"State": "CO",
"Locations": [
{
"LocationId": "LOC-101",
"Occupancy": "Office",
"CoverageA": 650000,
"CoverageB": 125000,
"Deductible": 2500
},
{
"LocationId": "LOC-102",
"Occupancy": "Warehouse",
"CoverageA": 1200000,
"CoverageB": 300000,
"Deductible": 5000
}
]
}
}Illustrative request for a policy covering an office and a warehouse. All locations and amounts are fictional.
Step 2
Check whether the workbook can become a service.
At upload, XSheet analyzes every formula and lists anything it cannot support, each with its sheet and cell, before it builds a version.
Workbooks that depend on something a calculation service cannot reproduce faithfully, such as external links, macros or precision as displayed, are rejected with a clear reason.
Each upload becomes an immutable version, and uploading the same file again returns the existing version. A later upgrade of XSheet never changes the results of an existing version. After an engine upgrade, the same workbook uploaded again becomes a new version, and its promotion shows the engine change before anyone approves it.
A new version can be tried in development straight away, while its full verification completes.
XSheet supports a growing set of Excel functions. Each one has its own test cases, and its behavior is checked against Excel itself.
Step 3
Build the calculation that will answer API requests.
XSheet prepares each version before it serves calls, so a rating workbook like the one measured on the Performance page evaluates in microseconds, without Excel.
A version is fixed once it is built, so the same inputs always produce the same results.
Each version runs isolated from the platform and from every other service, with no access to the network or to files and with fixed limits on memory and time. If a calculation fails or goes over a limit, the caller gets a clear error, and the platform and every other service keep running.
Step 4
Compare the results with Excel.
Before a version can serve calls, its results are compared with the values Excel calculated and saved in the workbook, to 15 significant digits.
XSheet also runs a second check on each version, on the saved case and on generated inputs. If that check disagrees, the version cannot be used.
A difference from the values Excel saved is reported down to the cell and blocks promotion into protected environments. The results make up the version’s verification report, which approvers see in the promotion request.
Step 5
Connect your application to the model.
Callers send inputs and get typed outputs back, with the version that answered and a request ID.
Unknown or missing fields and wrong types are rejected together, each with a JSON pointer to the field. An Excel error in a result, such as #N/A or #DIV/0!, comes back as data, and the request still succeeds.
Response
{
"request_id": "req_01j9x4…",
"version": { "number": 7 },
"outputs": {
"FinalPremium": 4210.75,
"Rate": { "error": "#N/A" }
}
}Per service, optional
Versions chosen by rules, inputs reshaped by transforms.
Both are optional and change only through promotion. Each recorded call’s receipt names which rule and which version answered.
-
Decision table
Conditions on the inputs, such as state, segment or effective date, decide which version answers each request. The table is edited like a spreadsheet, with paste from Excel, and overlaps and gaps show up while you edit. At promotion, XSheet proves that no two rows overlap and that no combination is left uncovered.
-
Transforms
Expressions map the caller’s request to the workbook’s inputs, and the outputs back to the shape the caller expects. Paste a sample request to see the transformed inputs straight away. Transforms run isolated, within strict limits.
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.