API-Enabled (Headless) Front-End Portal Capabilities

Hello, and welcome. I’m Spati Kavle, senior market strategy lead for policy administration with Origami Risk, and I’m glad you’re interested in learning more about our new headless functionality for our policy administration platform. This API enabled presentation allows clients to offer a fully customized and branded front end experience for policyholder quote, bind, and issue. I’m joined by Linus Concepcion, senior product engineer and cofounder of Origami Risk. I’ll pass it over to him to start the demo. Thank you, Swati, for that introduction. What we’re going to talk about today is the new quote and bind API that’s been added to the Origami API. Just as a refresher, these are the details of the Origami API. It is a REST based based API that gives you access to all of Origami’s domains. That this includes custom entities that may have you may have set up for your account or custom fields that may you may have added to your tables. It enforces security and validation configurations, and it exists in both the staging and live environments. What it does not give you, is a a simple way to access the API to create new quotes for complex policies with many rules that may be applicable. This is the perp this is the purpose for the new quotes API and the metadata API. In particular, the quotes API gives you, these services. Let’s talk about quote initiation first. So what we what we have built is a fine grained REST based API. What this means is that you need to call our API for the individual records that make up a policy. So a policy could have multiple schedule records. They have vehicles. They have locations. Locations may have coverages. Vehicles may have coverages, and coverages may have sub coverages. Each of these are individual records in the system. There will be an API for each one to access them. The key part of this is that these APIs are dynamic, which means as you configure Origami and build your rating programs, we do not have to make changes to our API to make those changes available to a system that needs to use this quoting API. So here, I have a policy portal, and this portal is built outside of Origami. It’s a standard ASP dot net source code that uses this API to show how you could use it to do quote intakes. So in order to show the quote intake portion, we’re gonna click on the new quote button here, and you’ll notice the system will ask for an effective date, which I’ll leave as default. Then it asks for a domicile. This list of states here is driven by how Oregonry is configured. So there is an API that allows you to query for the list of applicable states for a given effective date. It also allows you to pick lines of business. For this demo, we’re just going to do commercial auto. And so as part of the intake portion, you can fill in, fields at the policy level. So I have created a screen here that will take in, basic policy information, and I’m just going to fill in the top level information and click on the next button. So what this system will do at this point is it will invoke the post method on our API to submit the policy level information to Oregon. Now what I want to talk about is a very important part of our API. So one of the challenges of building a portal is, as you may know, there are hundreds of rules that may come into play for doing a court intake. The the data elements you need to collect, which ones are required, what value what values need to be in the drop down lists. If you’re collecting limits and deductibles, they you may have different options depending on the state you’re selecting. And what you really don’t want to do is you don’t want to duplicate this information in your portal source code. Ideally, when you’re designing your portal UI, you should be able to query origami for this information so that your UI can be dynamic. The idea is to always have up to date applications. So what field metadata gives you is a lot of information given a particular domain. So to show how this works, we will jump back to our application. And what we’re seeing here is just at we’re still at the policy level, but now we’re collecting information, that’s specific to the auto line of business. So these fields here and it doesn’t really matter what I pick for for the demo, but these fields here are all rendered by logic that is reading the metadata that is being returned. So, including what’s available in the drop downs, these are not hard coded anywhere. Anywhere we have a multiselect list, we do not we do not hard code that there is a field called liability symbol, and it’s a multiselect list, and these are the options. These options were returned by the metadata API, so these will always be up to date and in sync with how Origami is configured. Go next. And, we will continue to show more of the field metadata as I go through the rest of this demo. The other part of filling out a quote are adding your schedules and exposures. These are your buildings. These are your vehicles. This may be your payroll schedule if if your workers’ comp. This this API is also dynamic. If you look at the API that’s shown in the slide, it doesn’t really mention vehicles or locations. It just has a a placeholder for domain. This means that this API is usable for any domain that is a schedule that has been added to Oregon. I have a way here to add locations and vehicles. So I’m just going to do a location. So now I have a location entered, and now I have to enter a vehicle. So a vehicle in my particular configuration belongs to a location. So I need to pick a location first, and then this particular setup has a way for me to enter a VIN number so that it can autofill a lot of the vehicle information for me. So let me just fill that in. Okay. So what I just showed is the API giving you access to integrations that may have been configured in the system. In this particular case, we have configured for this account a VIN lookup. That is available that will be made available through the API as well. So the the VIM lookup is actually done in the Origami server side, but the data is sent back to your, to your portal so you can render it in your UI. And to show, some of the dynamicness of what the metadata API gives you, you’ll notice that as I select different vehicle types here, nothing really changes unless I pick special, in which case another field appears. So this is an example of a field be being visible depending on the selection on another field. So the API also gives you access to coverages and sub coverages. For an auto quote, you can have coverages both at the policy level, and you can have coverages for each individual individual vehicle. Our particular demo is going to show adding coverages at the vehicle level. But in addition to being able to add and remove coverages, you also need to determine coverage applicability. So there may be rules depending on the state or your rating company or the effective date of the policy where certain coverages may not be applicable. You may also have rules where coverages are mutually exclusive. So if you pick one coverage, another one might may not be available. These are rules, again, you do not wanna hard code in your system. So there is an API that you can query to grab applicable coverages. So let me show that here. In the add coverage button, our API, depending on the state I selected and the the line of business and and the and the details in the vehicle gives me a list of possible coverage types. Here, I’m going to pick collision. And, again, using the metadata API, the system can determine what fields need to show up because of the coverage I picked and because of the state it’s in. And I can fill in this data. So let’s just add a couple of coverages for this demo, and then we’re back. Finally, in schedules, we also have an API that gives you access to schedule rating. So this is the scheduled rating details that may affect the rating of this policy. I’m just going to fill in some basic information here. So as you saw, Origami does validate as you submit. So, really, if I go to the validate screen here, it should find no errors. But I’m going I want to trigger an error for this demo. So I’m going to update the data behind the scenes so that I can trigger trigger an error. What we want to see what we wanna see here is a way for the system to look at the entirety of what you’ve submitted so far and check to see if there are any issues, with what you’ve submitted. We have an API that we’ve provided that it that can be called synchronously or asynchronously that runs all the validation rules and returns a list of errors, including which record which records may be missing. So behind the scenes, I made a modification to remove the make field in the vehicle we entered, and that’s how it found this error. So I can click on this link, which will take me to this part of the system, back to the vehicle where I can refill in the validation error, click on save and finish, and then I can rerun the validations. You noticed there was a wave button in my validation screen. Our API also gives you the ability to wave or unwave certain validations that you may think are not not that important. So there are validations that can be considered warnings, and there are validations that cannot be waived. And finally, we will talk about rating and issuing. So now that you’ve entered and validated your quote, you want to calculate a rate for it. So we we have provided a rating API that also can be run synchronous and asynchronously. So I’ve already run it for this particular proposal. You’ll see that it did calculate a premium. And the final part after a premium is calculated is the issuing part. Origami also gives you access to various billing options that may have that you may have configured in your system. In this particular case, this system is configured to to allow for a full pay, quarterly pay, or monthly pays. The API actually calculates, the dates and the due amounts for each of the invoices that will be generated depending on the option the user selects. So I’m presenting the all all three of those options here. I’m going to pick quarterly, and that will run the final issue API. So now, the process is done, and you have fully, from this from the start, created a brand new quote, ran through, created all the schedule records that are relevant to the to that quote, added coverages, rated it, and then validated, then rated it, and finally, issued the policy. So the final result result here is a policy record has been created in the system along with all the billing information and forms, that should be applicable. So that is an overview of the quote and bind API. In order to learn more, please contact your service representative. We also have the swagger APIs available, in live dot origami risk dot com slash origami a p I as well as staging dot origami risk dot com slash origami a p I. Thanks very much for your time. That concludes my demo.