EFS Batch & API Filing

The SLAI’s Batch Upload feature allows members who can extract data from their management system to upload it in bulk form to the EFS and receive an instantaneous response indicating acceptance of the batch or detailing errors in the batch.  The Batch Upload feature does not automate SLAI Confirmation pages for uploaded batches, however, this process can easily be automated on the user end by downloading data from the batch that was uploaded and reformatting it to resemble the confirmation page.

Setting up, testing and implementing the Batch Upload feature is not for users, but rather solely for programmers or IT support personnel who are familiar with the requirements and standards for the XML, csv and flat file data transfer formats and can sufficiently familiarize themselves with the EFS so they can reliably navigate through the testing process.

When your membership was established, the licensee designated an EFS Administrator in the membership forms. If you don’t know who your EFS Administrator is, contact the EFS Help Desk. That EFS Administrator can set up user accounts and grant appropriate permissions for any programmers and other personnel that will be working on developing your Batch Upload capabilities.  Instructions for setting up accounts can be found on our User Administration help page, however, they will need to set the accounts up on the sandbox system instead of the production system (see below for a link to the sandbox system). For security purposes, each user should always have their own login.

The are two files in the Batch Upload Info zipped folder.  The General Information file (SLAI-eFile-BatchUploadSpecs.xls) contains a brief description of the EFS Batch Upload Feature, a listing of permissable Coverage Codes and the specifications for txt and csv uploads.

The XML Schema file (SLAI-eFile-Schema.xsd) will check that your xml file is well formed and that tags are used correctly.  For many fields, the schema will validate certain aspects of the data (correct data type, within specified range, etc.).

Now that access to the test system has been established and the Batch Upload information and specifications have been reviewed, you can begin coding and testing on the sandbox system.  During this process, if there is an error message or anomaly you don’t understand, reach out to David Ocasek with any questions and he will happily answer them or refer you to other staff that can assist you.

Never do any testing on the production system. Once you are ready to go live with your Batch Uploads, have your EFS Administrator set up the appropriate user account(s) on the production system and begin processing your Batch Uploads.

About Automating SLAI Confirmation Pages

Once a batch has been successfully uploaded, you can click on the “View” button on the Upload Batch screen and you will be redirected to the Your SLAI Filings screen displaying just that batch.  At this point, you can click on one of the black download buttons at the top of the screen to download the data from that batch in your desired format.  This download contains the SLAI Confirmation numbers, date and time of submission, all calculated taxes and fees and the complete filing record.  From here you can automate creation of confirmation pages in a number of ways.  Some users have been able to do it using macros within Excel, or using the Mail-Merge feature of Word.  In other situations, programmers have been able to write simple programs that generate the confirmation pages using the downloaded file as a data source.  Print out a real confirmation page from the EFS and use it as your guide when creating your own.

Sandbox System:Click Here for Sandbox System
Production System:Click Here for Production System

The SLAI’s API allows your computers to automatically send postings of your Illinois surplus line policies and endorsements to our system for filing, and to receive a response back that includes the SLAI confirmation number and all calculated taxes and stamping fees. Once your system captures this response, it can then print the appropriate information on the policy or generate an SLAI confirmation page that can be attached to the policy or endorsement before delivery to the insured as required by law.

The API is not for users, but rather solely for programmers who are familiar with the requirements and web standards for Representational State Transfer Application Program Interfaces (RESTful APIs), HTTP protocol and the JSON data format.

When your membership was established, the licensee designated an EFS Administrator in the membership forms. If you don’t know who your EFS Administrator is, contact the EFS Help Desk. That EFS Administrator can set up user accounts and grant API key-generation permission for any programmers that will be working on developing your API capabilities by following the instructions on our User Administration help page, however, they will need to set the accounts up on the sandbox system instead of the production system (see below for a link to the sandbox system). When setting up logins for the programmers, the EFS Administrator should remember to grant them permission to generate an API key, as well as data entry, bulk entry and reporting. For security purposes, each user should always have their own login.

Once your programmer has an account on the sandbox system, they can access the swagger data page (login is required). This is the link to the swagger data page on the sandbox system. There is an identical page on the production system, but let’s stay in the sandbox for now.

There are also additional important details regarding general specifications for the data fields (available without a login) that can be found in an excel spreadsheet located here.

Once a programmer has access to the test/sandbox system, they should generate an API key for use in their testing. The key is generated in the “GENERATE API TOKEN” panel of the Edit Profile section (accessed by clicking on your name in the upper-right corner of the screen). The API key is used for authentication of POSTs as described on the swagger data page. An API key is tied to the member number and login from which is generated. So if you are user jdoe@abc.com with SLAI member number 9876, any POSTs made using the API key you generate will post to member number 9876 and will show as posted by jdoe@abc.com.

Now that you have access to the test system and have reviewed the API/swagger information, you can begin working on your end, creating the code that will interface with the SLAI sandbox API, sending posts and receiving response data. You should test to see that your code creates only valid posts. During this process, you are welcome to reach out to David Ocasek with any questions and he will happily answer them or refer you to other staff that can assist you.

Never do any testing on the production system. Once you are ready to go live with your API, we’ve found that a good practice is to create an alias email account for the API filings. So if your name is Betty Smith and your email is betty@abcinsurance.com, you might create an alias email account called betty_api@abcinsurance.com. Have your EFS Administrator set up a login for that email on the production system (with appropriate permissions) and generate the production API key from that account. That way, all API filings will be identified with this unique email account and will be distinguishable from filings made by other users using other methods.

Sandbox System:Click Here for Sandbox System
Swagger Data on Sandbox:Click Here for Swagger Data
Production System:Click Here for Production System