Makeability Lab Portal

Lab networks · capabilities · lens & frame libraries · calculator connecting…

Overview

Labs

LabNetworkTypeStatusStandardExpediteLens productsPriority

Labs

Select a lab, or create one.

Lens products

Select a lens product, or create one.

Frames

Select a frame, or create one.

Catalogs

An order arrives in the client's codes and has to be made in the lab's. Each side maps to the shared catalog rather than to the other, so twelve accounts and twenty networks are thirty-two lists to keep, not two hundred and forty pairs. What can actually be ordered is the overlap, and it is computed here rather than kept by hand.

Whose catalog

Saving replaces this owner's list. A product dropped from the list stops being sold: the list is the catalog, so merging would leave a withdrawn product orderable because nobody deleted the row.

Their codeTheir name for itShared catalog entryAlso matches (regex)

Order

Prescription

SphCylAxisAddAdd 2PDNear PDSeg htOC htHt dirPrismBasePrism 2Base 2BC

Frame

Extras

Coatings, tints, mirrors and edge work on the order. A lab that will not do one is ruled out by it, and some add lead time.

EyeTypeDescriptionSKUCode 1Code 2Comment

Lens and labs

The office and company decide the account, and so the contract, the routing rules and which of the client's own lens codes apply. Leave them blank to ask the whole catalog. The labs chosen are sent as the office's mapped labs, the list a practice management system sends to say which labs an office may see. Both buttons send the same order.

Fill in a prescription and a frame, then check makeability.

Networks

Select a network, or create one.

Accounts, offices and contracts

Administrator only. An office does not order from every lab that exists. It orders under a contract, and the contract decides which labs are eligible, how many of them are worth asking, and where particular work is committed. Check Entitlement to see what one office may actually use today, and why every other lab is out.

Accounts

Select an account, or create one.

Routing rules and engine settings

Administrator only. Rules are evaluated top to bottom and the first matching rule that assigns a lab wins; every other action of every matching rule (only, exclude, expedite, note) is applied as well. Editing here changes a draft only — Test draft reports what the draft would do without writing anything, and nothing reaches the server until you press a save button.

Evaluation order

Order matters: move a rule up to let it decide before the ones below it.

Select a rule, or create one.

Test the draft — nothing is saved

Sample orders are evaluated with the rules and settings currently in the editor and compared with the saved ones; changes are highlighted in amber. Save all writes the whole document, and only right after a test of exactly what you are about to save.

Ctrl / Cmd-click to pick several. Testing never writes anything.

Monitor

Every call to the makeability endpoint, newest first: what arrived, what was answered, and which catalog product each lens on the order resolved to. Calls that were refused are here too, with the header the caller put its key in and whether that key is the one this deployment expects. Keys themselves are never recorded.

Nothing recorded yet.

Pick a call on the left to see what was received and what was answered.

Change log

Every change to labs, rules, contracts, catalogs and users, newest first, with who made it. Recorded from the single point every write passes through, so nothing that changed the configuration is missing. Credentials are never recorded.

Connect a practice management system

Everything a caller needs to send this service an order and get a lab list back. The service only ever answers: it never calls out, so there is nothing to register and no callback to configure.

Settings

Visionworks' LabListingAPI is pointed at a qualification service by three databag settings.

SettingValue

A request that works


      

A malformed order comes back 200 with qualApiStatusCode saying what was wrong and an empty list: the published contract documents one response for this call, and the caller is a point-of-sale screen where an exception is not an answer anybody can act on. The contract forbids extra fields, so the list of what was wrong is not in that reply - post the same order to /explain for it. A body that is not readable JSON is 400, missing or wrong key is 401, over 1 MB is 413: in those the operation never began. Add /explain to either path for the full decision trace, which is the one to reach for when a lab comes back unselectable and you want to know which rule did it.

API

Full reference: Swagger UI · openapi.json

MethodPathPurpose

Examples