Informações Gerais

A interface de programação/integração disponível no aplicativo Indexmed é uma API Restful. Abaixo você pode entender um pouco mais sobre este conceito e analisar como o aplicamos.

API

O acrônimo API que provém do inglês Application Programming Interface (Em português, significa Interface de Programação de Aplicações), trata-se de um conjunto de rotinas e padrões estabelecidos e documentados por uma aplicação A, para que outras aplicações consigam utilizar as funcionalidades desta aplicação A, sem precisar conhecer detalhes da implementação do software.

Desta forma, entendemos que as APIs permitem uma interoperabilidade entre aplicações. Em outras palavras, a comunicação entre aplicações e entre os usuários.

Arquitetura REST

A Representational State Transfer (REST), em português Transferência de Estado Representacional, é um estilo de arquitetura que define um conjunto de restrições e propriedades baseados em HTTP. Web Services que obedecem ao estilo arquitetural REST, ou web services RESTful, fornecem interoperabilidade entre sistemas de computadores na Internet. Os web services compatíveis com REST permitem que os sistemas solicitantes acessem e manipulem representações textuais de recursos da Web usando um conjunto uniforme e predefinido de operações sem estado. Estas operações são comumente conhecidas como Verbos/Métodos. Veja abaixo o conjunto de operações disponíveis em nossa API.

Métodos HTTP

Quando você vai fazer uma requisição, é preciso que você especifique qual o método será utilizado. Os métodos HTTP, identificam qual a ação que deve ser executada em um determinado recurso. Em nossa API disponibilizamos os seguintes 4 métodos:

GET Solicita a representação de um determinado recurso. É definido como um método seguro e não deve ser usado para disparar uma ação (remover um usuário, por exemplo).
POST As informações enviadas no corpo (body) da requisição são utilizadas para criar um novo recurso. Também é responsável por fazer processamentos que não são diretamente relacionados a um recurso.
DELETE Remove um recurso. Deve retornar o status 204 caso não exista nenhum recurso para a URI especificada.
PUT Atualiza um recurso na URI especificada. Caso o recurso não exista, ele pode criar um. A principal diferenteça entre POST e PUT é que o primeiro pode lidar não somente com recursos, mas pode fazer processamento de informações, por exemplo.

Status

Toda requisição recebe um código de resposta conhecido como status. Com o status é possível saber se uma operação foi realizada com sucesso (200), se ele foi movida e agora existe em outro lugar (301) ou se não existe mais (404).

Existem muitos status divididos em diversas categorias. Abaixo, seguem os códigos que utilizamos em nossa API:

200 OK A requisição foi bem sucedida.
301 Moved Permanently O recurso foi movido permanentemente para outra URI.
302 Found O recurso foi movido temporariamente para outra URI.
304 Not Modified O recurso não foi alterado.
401 Unauthorized A URI especificada exige autenticação do cliente. O cliente pode tentar fazer novas requisições.
403 Forbidden O servidor entende a requisição, mas se recusa em atendê-la. O cliente não deve tentar fazer uma nova requisição.
404 Not Found O servidor não encontrou nenhuma URI correspondente.
405 Method Not Allowed O método especificado na requisição não é válido na URI. A resposta deve incluir um cabeçalho Allow com uma lista dos métodos aceitos.
410 Gone O recurso solicitado está indisponível mas seu endereço atual não é conhecido.
500 Internal Server Error O servidor não foi capaz de concluir a requisição devido a um erro inesperado.
502 Bad Gateway O servidor, enquanto agindo como proxy ou gateway, recebeu uma resposta inválida do servidor upstream a que fez uma requisição.
503 Service Unavailable O servidor não é capaz de processar a requisição pois está temporariamente indisponível.

Regras de acesso

Abaixo seguem as regras de acesso à API Indexmed:

✓ Chamadas apenas através do protocolo HTTPS
✓ Dados de acesso válidos e enviados corretamente. Para novas integrações, utilize Bearer token.
✓ A integração nunca amplia as permissões do usuário responsável. A consulta, inclusão e alteração seguem as mesmas regras de acesso da plataforma, incluindo assinatura, empresa e unidade quando aplicáveis.
✓ Respeitar os limites publicados em cada operação. A API considera credencial, IP e rota e retorna 429 com Retry-After quando o limite é excedido.
✓ Estar ciente que as ações via interface refletem automaticamente no aplicativo. Qualquer inclusão/atualização/exclusão de dados é definitiva

Limites de requisição

Tipo de operação	Segundo	Minuto	Hora	Dia	Semana
Consultas padrão	10	300	5.000	25.000	125.000
Gravações	2	60	600	3.000	15.000
Operações de maior custo	1	20	200	1.000	5.000

Consulte a documentação de cada método para verificar qual limite é aplicado a ele.

Autenticação

Bearer token é o modelo recomendado. Ele cria credenciais por sistema consumidor, com expiração, renovação e revogação independentes, sem enviar a Chave API em todas as chamadas.

Authorization: Bearer {access_token}

O Basic Authentication continua disponível para integrações existentes até 1º de abril de 2027. Após essa data, somente Bearer token será aceito.

Authorization: Basic {credenciais em base 64 no formato ID Usuário:Chave API}

Para saber mais sobre autenticação acesse:

Autenticação na API