Extensibilidade

Os padrões do Open Insurance podem não cobrir todas as possibilidades de objetos retornados ou APIs que os participantes desejam expor. Os participantes podem ter o desejo de realizar inovações sobre os padrões definidos oferecendo mais dados afim de atender demandas específicas de mercado. É nossa intenção que os padrões definidos não apenas permitam estas extensões como também sirvam como base para futuras alterações na própria definição dos padrões.

No entanto, é importante que um participante que esteja querendo estender as APIs não impeça um consumidor que foi projetado para consumir apenas o endpoint padrão funcione corretamente.

Para atender tanto as demandas de quem deseja estender as APIs (participantes) quanto as demandas de quem irá realizar o consumo (consumidor das APIs), foram definidos os critérios abaixo.

É possível estender os padrões nos seguintes aspectos:

O participante pode oferecer uma API completamente nova que não está coberta nos padrões definidos
O participante pode oferecer novos endpoints em uma API que já foi definida no padrão
O participante pode oferecer campos de entrada e retorno opcionais para um endpoint que já foi definido no padrão

ID dos participantes

Cada participantes terá um ID que representa a sua instituição. Os participantes da atual versão estão listados abaixo:

ALLI - ALLIANZ SEGUROS S.A.
AUST - AUSTRAL SEGURADORA S.A.
BRAS - BRADESCO SEGUROS S.A.
BRCA - BRASILCAP CAPITALIZAÇÃO S.A.
BRPR - BRASILPREV SEGUROS E PREVIDÊNCIA S.A.
BRSE - BRASILSEG COMPANHIA DE SEGUROS
BTGS - BTG PACTUAL SEGUROS S.A.
CAIS - CAIXA SEGURADORA S.A.
CAIV - CAIXA VIDA E PREVIDÊNCIA S.A.
CARD - CARDIF DO BRASIL VIDA E PREVIDÊNCIA S.A.
CHUB - CHUBB SEGUROS BRASIL S.A.
EULE - EULER HERMES SEGUROS S.A.
HDIG - HDI GLOBAL SEGUROS S.A
HDIS - HDI SEGUROS S.A.
ICAT - ICATU SEGUROS S.A
ITAS - ITAU SEGUROS S.A.
LIBE - LIBERTY SEGUROS S.A.
MAPF - MAPFRE SEGUROS GERAIS S.A.
PORT - PORTO SEGURO COMPANHIA DE SEGUROS GERAIS
PRUD - PRUDENTIAL DO BRASIL SEGUROS DE VIDA S.A
SAFR - SAFRA SEGUROS GERAIS S.A.
STDA - SANTANDER AUTO S.A.
STDC - SANTANDER CAPITALIZAÇÃO S.A.
SOMP - SOMPO SEGUROS S.A.
SULA - SUL AMÉRICA SEGUROS DE PESSOAS E PREVIDÊNCIA S.A.
TOKI - TOKIO MARINE SEGURADORA S.A.
TOOS - TOO SEGUROS S.A.
XPVP - XP VIDA E PREVIDÊNCIA S.A.
XS3S - XS3 SEGUROS S.A.
XS4C - XS4 CAPITALIZAÇÃO S.A.
ZURB - ZURICH BRASIL COMPANHIA DE SEGUROS
ZURS - ZURICH SANTANDER BRASIL SEGUROS S.A.

Participantes que desejam estender os padrões devem adicionar seu prefixo para identificar todas as extensões. Campos adicionais no retorno de endpoints existentes ou em novos endpoints devem usar o prefixo do participante. O prefixo deve ser no formato exposto ao lado (4 letras) e não devem haver prefixos duplicados entre os participantes.

Nesta documentação, quando tivermos que nos referir ao prefixo do participante, o termo <PID> será utilizado.

Novas APIs

Quando a extensão for a criação de uma nova API, o participante deve adicionar seu prefixo a URI antes do nome da nova API, conforme exemplo abaixo.

Por exemplo, uma API definida pelo padrão seguirá o seguinte formato: <host> / open-insurance / <api> / <versão> / <recurso>

Uma API estendida por um participante deverá estar no formato abaixo: <host> / open-insurance / <PID> / <api> / <versão> / <recurso>

Para os endpoints definidos dentro da estrutura acima, os atributos dos payloads não precisam conter o prefixo do participante, pois entende-se que todos os recursos da API estendida não conflitam de nenhum modo com as definidas pelo padrão.

Importante:

Este método não deve ser usado para criar duplicações modificadas dos *endpoints* já definidos no padrão.
Os novos *endpoints* devem atender às convenções e princípios do padrão, incluindo convenções de nomes e tipos de dados.

Novos endpoints em APIs existentes

Quando o participante desejar adicionar um novo endpoint em uma API já especificada no padrão, o participante deve incluir seu <PID> como prefixo do recurso que será implementado.

Por exemplo, assumindo a existência do endpoint abaixo para consulta dos sinistros de um seguro de automóvel: <host>/open-insurance/insurance-auto/v1/{policyId}/claim

Se o participante deseja adicionar um novo endpoint que resume os sinistros por um período, então este endpoint poderia ser definido como: <host>/open-insurance/insurance-auto/v1/{policyId}/<PID>-claims-movement

Importante:

O prefixo deve ser adicionado antes do nome do recurso seguido por um hífen. (-)
Como o *endpoint* é novo, os atributos do *payload* de requisição e resposta não precisam conter o prefixo do participante.
Se um *endpoint* possuir múltiplos níveis na URI do recurso, apenas o recurso mais a direita deverá possuir o prefixo do participante.
Os novos *endpoints* devem atender às convenções e princípios do padrão, incluindo convenções de nomes e tipos de dados.

Campos de retorno adicionais em um endpoint existente

Quando o participante desejar adicionar um novo campo ao payload de resposta, o atributo deverá receber o prefixo do participante seguido por um hífen <PID>-.

Se um objeto estiver sendo adicionado ao payload de resposta, apenas o nome do objeto precisa receber o prefixo. Qualquer atributo dentro do novo objeto pode ser nomeado normalmente.

Importante:

Campos existentes não devem ser modificados. Isto inclui adicionar novas opções em campos do tipo Enum.
Um campo obrigatório não deve se tornar opcional como resultado de uma extensão.
*Payloads* de requisição também podem ser estendidos, porém o resultado ainda deve respeitar os padrões definidos caso o campo de extensão não tenha sido utilizado (por definição, campos adicionais no *payload* de *request* devem ser opcionais).
Parâmetros de *query* podem ser adicionados desde que seguidas as mesmas premissas de um novo campo no *payload* de requisição (com prefixo, não obrigatório e sem efeitos colaterais caso não seja informado).
Parâmetros por *header* podem ser adicionados desde que seguidas as mesmas premissas de um novo campo no *payload* de requisição. No entanto, seu prefixo deve estar no formato `x--`.
Novos campos devem atender os padrões definidos de nomenclatura e tipos de dados.

Parâmetros query adicionais

Quando for adicionado um novo parâmetro de query a um endpoint existente, o novo parâmetro deve ter o prefixo <PID>-, evitando assim colisões com parâmetros já existentes.

Filtro de Dados

Opcionalmente, a entidade transmissora de dados poderá realizar filtro de dados através de query de entrada, baseado em campos que julgue relevante para a melhor experiência do cliente.
A informação de quais possibilidades estarão disponíveis (query parameter) deverá constar em documentação adicional disponibilizada pela entidade transmissora.

Extensão do versionamento

Como descrito na seção calendário, o versionamento existe apenas no nível das APIs e não no nível dos endpoints, no entanto caso seja necessário realizar versionamento de um endpoint customizado, o participante poderá utilizar o header x-<PID>-v para que o consumidor possa especificar qual versão do endpoint está requisitando.