Try it: Here
API Summary
Purpose
The RMIS Document API allows RMIS customers to fetch the binary versions of a document for storage in their own system.
The API is easy to use, and can be called with a web browser or automated with any system that can make HTTP requests.
Note: The API consumer must save the binary file data locally and decode it before the file can be viewed.
Calling the Document API
Calling the Document API
The request is a GET request to the base URL:
https://api.rmissecure.com/_c/std/api/DocumentAPI.aspxThere are 6 URL parameters required with this request
- ClientID - The broker-specific RMIS client ID
- Pwd - The broker-specific RMIS API Password
- DocumentType - What type of document is being retrieved (See Below for valid types)
- DocumentID - The ID of the document (from the Expanded Carrier API response)
- InsuredID - The carrier-specific RMIS identifier
- Version - Which version of the API to call (1 is the current version)
curl --request GET \ --url 'https://api.rmissecure.com/_c/std/api/DocumentAPI.aspx?clientID=1234&pwd=MyPass123!&documentType=Certificate&documentID=12292307&insdID=541599&version=1' \ --header 'accept: application/json'
<?xml version="1.0" ?> <RMISDocumentAPI> <Header> <TimeStamp>9/30/2024 8:36:48 AM</TimeStamp> <API>RMISDocumentAPI</API> <Version>1</Version> <Result>SUCCESS</Result> </Header> <DocumentInfo> <DocumentType>Certificate</DocumentType> <DocumentID>12292307</DocumentID> <DocumentTitle>certificate.TIF</DocumentTitle> <DocumentDate>Thursday, September 19, 2024 06:09:15</DocumentDate> <DocumentFileType>TIF</DocumentFileType> <DocumentFileSizeInBytes>81844</DocumentFileSizeInBytes> </DocumentInfo> <DocumentData>**Base64 encoded Binary document data**</DocumentData> </RMISDocumentAPI>
Document Types
Document Types
Type
Description
File Format
Finding the ID
Certificate
The certificate document image for each insurance coverage.
TIFF Certificate documents are always stored as multipage TIFF files.
Note:
The return document type is spelled “TIF” in the XML.
Certificate document IDs can be found in the
<RMISImageID>
node of the<Coverage>
node.The ID is always an integer.
W9
RMIS captures W9 data electronically as part of the registration process.
PDF Only
W9 document IDs can be found in the in the
<W9ID>
node under the<W9>
node.The ID is always an integer.
Agreement (main agreement)
RMIS captures agreements two ways, as a Main Agreement or as ClientAgreement. Typically, when a customer only has a single agreement for the insured to sign, we capture the agreement as a ‘Main’ agreement only.
If the insured needs to sign multiple agreements, they are stored in the ‘sub agreements’ section. The data is always stored internally as pure HTML.
For the purposes of this API, requests to fetch an agreement will result in a PDF file that is generated dynamically from the HTML stored in the system.
PDF only
Main agreement IDs can be found in the
<agreementID>
node under the<Agreement>
node.The ID is always an integer.
ClientAgreement (sub agreements)
There is no functional difference between agreements stored in the Agreement (main) section or the ClientAgreement (sub agreements) section.
PDF only
Agreement document IDs can be found in the
<AgreementID>
node under the<ClientCarrierAgreements>..<Agreement>
nodeThe ID is always an integer.
Document
RMIS captures uploaded files (uploaded by the insured or the client) into an ‘electronic file cabinet’.
These files are typically uploaded during a registration, but can also be uploaded post registration by the insured or the client, and are always associated with a particular client and insured. In addition, the files are always uploaded with a client defined document type ‘key’ (eg. “W-8BEN” or “Corrective Action Plan”.
Currently can be: “PDF”, “TIF”, “JPG”, “PNG”, “GIF”, “BMP” or “TXT”
The document ID can be found in the
<DocumentID>
node under the<Documents>..<Document>
node of the ExpandedCarrierAPI XML (v9 or above only)
Decoding the document data
Decoding Documents
The RMIS Document API will return basic metadata about the document retrieved, as well as the binary file data serialized as a base64 encoded string.
It is the responsibility of the API consumer to extract the binary information, and then to decode the binary data into the correct file type for saving or viewing.
Note: The DocumentFileType node will contain the type of document that the binary data represents.
The consumer of the API must retrieve the encoded binary data within the DocumentData node and then decode the data to view or store the file.
Optionally, the consumer may also wish to compare the final file size with the DocumentFileSizeInBytes node to confirm that the file was retrieved completely with no missing information.