Nossas APIs foram desenvolvidas no protocolo de comunicação SOAP e toda solicitação deve ser realizada pelo método POST.
Os serviços disponíveis estão organizados por módulos como segue:
Geral – Cadastro comuns para todos os módulos;
CRM – Contas + Contatos + Oportunidades para fechar mais negócios e vender mais;
Finanças – Extrato multi-contas + Contas a Receber + Contas a Pagar + Fluxo de Caixa;
Compras, Estoque e Produção – Gerencie suas compras, estoque e ordens de produção;
Vendas e NF-e – Processo de Venda e Faturamento, emissão de NF-e, Cupons Fiscais, etc;
Serviços e NFS-e – Processo de emissão de Ordens de Serviço, Contratos e NFS-e;
Painel do Contador – Consulta de documentos fiscais.
Para cada módulo, há uma lista de serviços disponíveis:
Por exemplo, para acessar a API de clientes, deve-se utilizar a URL “https://app.omie.com.br/api/v1/” seguida do módulo “Geral” e depois pelo “Serviço”, como segue:
https://app.omie.com.br/api/v1/geral/clientes/
SOAP - Para realizar um consumo pelo protocolo de comunicação SOAP você precisará indicar / verificar as seguintes informações:
Content-Type: text/xml;charset=UTF-8
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsdl="http://app.omie.com.br/api/v1/geral/clientes/?WSDL" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<soapenv:Header>
<app_key>999999999999</app_key>
<app_secret>a1b2c3d4e5a1b2c3d4e5a1b2c3d4e5a1b2c3d4e5</app_secret>
</soapenv:Header>
<soapenv:Body>
... (Body da requisição em formato XML)
</soapenv:Body>
</soapenv:Envelope>
RESTFUL - Existe a possibilidade de fazer um consumo pelo protocolo de comunicação RESTFUL?
Não, mas estamos trabalhando numa nova plataforma que utilizará a protocolo REST e documentação Swagger.
JSON - Existe a possibilidade de enviar um JSON ao invés de XML?
Sim, para isso você deve observar o seguinte formato:
Content-type: application/json
{
"app_key": "999999999999",
"app_secret": "a1b2c3d4e5a1b2c3d4e5a1b2c3d4e5a1b2c3d4e5",
"call": "ListarClientes",
"param": [
{
... (Body da requisição em formato JSON)
}
]
}
CORS policy 1 – Como corrigir o seguinte erro:
Access to XMLHttpRequest at ‘https://app.omie.com.br/api/v1/geral/clientes/’ from origin ‘https://www.seusite.com.br’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
Neste caso, há uma tentativa de realizar o consumo diretamente pelo navegador, o que expõe as credenciais do usuário. A solução é criar uma API e consumi-la a partir do server.
CORS policy 2 – Como corrigir o seguinte erro:
Access to fetch at 'https://app.omie.com.br/api/v1/geral/clientes/' from origin 'https://localhost:8082/' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Neste caso, há uma tentativa de realizar o consumo pelo localhost, o que não é permitido. A solução é alterar o local de origem para um IP público e tentar novamente.
Rate limit – Estamos estudando alguns modelos para aplicar um rate limit em nossas APIs e assim, garantir maior disponibilidade e performance. Até essa definição, recomendamos, por boa prática, observar as seguintes situações:
Assim, no momento, por boa prática, recomendamos verificar as seguintes condições:
- Limite de até 240 requisições por minuto;
- Limite de até 4 requisições simultâneas por segundo para consultas;
- Sem suporte de requisições simultâneas para inclusão/alteração de dados;
- Requisições redundantes liberadas a cada 60 segundos (*).
(*) - É permitido consultar tantos registros diferentes quantos forem necessários. No entanto: Se tentar consultar o mesmo id 2 ou mais vezes seguidas, em até 60 segundos, apenas a primeira requisição retornará os dados. As demais retornarão uma mensagem indicando que aquela solicitação já foi realizada anteriormente. Passados os 60 segundos, a consulta será liberada novamente. A Implementação de um cache do lado da aplicação integrada evita que essa situação ocorra.
Quando o rate limit for ultrapassado, será retornado o HTTP Code 429 indicando que o limite de requisições foi excedido, conforme o exemplo abaixo:
C# - Valores não são enviados para o Omie:
Consumo via GET – Indisponível. Requisições com GET não são seguras, pois expõe os seus dados tornando sua aplicação vulnerável a ataques ou mesmo sequestro de dados. Caso você execute, a consulta abaixo diretamente pelo seu navegador, receberá a seguinte mensagem:
Requisição:
https://app.omie.com.br/api/v1/servicos/os/?JSON={"call":"ListarOS","app_key":" 38333295000","app_secret":" 4cea520a0e2a2ecdc267b75d3424a0ed","param":[{"pagina":1,"registros_por_pagina":50,"apenas_importado_api":"N"}]}
Resposta:
{"status":"400","message":"Consumo indevido [GET]. Consulte nosso time de suporte através do chat disponível em nosso site."}
Solução: Altere o método de consumo para POST e envie os dados no BODY da sua requisição.