Welcome to the Omocom REST API documentation!
Here you find a description of how to work with the Omocom API and examples of uses. It also outlines the normal sequence of API calls.
For general Omocom information visit omocom.insurance. Any questions can be sent to hello@omocom.insurance!
Swagger API Reference
This site contains documentation on how to work with the Omocom API. The full reference documentation is found at api.omocom.se/swagger/index.html.
Client Generation
The Swagger API Client reference page above contains an OpenAPI 3 .json
definition of the Omocom REST API which can easily be used in e.g.
NSwag to generate client code in C# or Typescript. This way you can interact with Omocom using proper objects,
with type support, without having to build the REST objects manually:
// Example creating user by generated code
var userReq = new UserReq
{
FirstName = "John",
LastName = "Smith",
UserId = internalUser.Username
};
var usersClient = new UsersClient(baseUri, httpClient);
var ownerResp = await usersClient.PostAsync(platformId, marketName, userReq);
The .json
file can also be imported in Postman to easily test out the API.
If you want some getting started-assistance to get going with generated code, just contact us and we'll try to help!
Onboarding Process
Typically, a client platform that wishes to integrate with Omocom through the API will get a starter pack with some links to this documentation, some tailored examples showing any specifics of the integration, and credentials allowing access to our Beta (sandbox) environment to use during development of the integration.
We will have a channel for communication (e.g. Slack or Teams) set up between the development teams to allow for quick resolution of an problems or questions that might arise.
Final Integration Sign-off
In the end, when you believe the integration is complete and there are no more open questions, Omocom will make a final validation of the integration before handing out the production environment credentials. This is done through a review of a typical insurance transaction.
To facilitate a review, you will create an as realistic as possible end-to-end transaction where all properties and values are like they will be in production, not just nonsense placeholders:
- User or users
POST
ed with all information - A complete
POST
of an Insurable Object - A full Insurance
POST
with all dates, properties and values present, and corresponding/accept
of the returned quote - Depending on the type of integration, any calls to
/activate
and/end
Once you have run through a full, realistic scenario you provide us with the resulting insurance number so we can go through logs and other artifacts, and hopefully provide production criterias and a succcessful go live.