Características da API
Recursos de imagem
Algumas características mencionadas estão intrinsecamente ligadas aos serviços que utilizam o recurso de imagem. Esses serviços são os seguintes:
- Content Classification
- Content Compare
- Content Extraction
- Content Extraction Async
- License Plate Recognition
- Vio Extraction
Extensões de arquivos suportadas
São suportados pela API os seguintes tipos de arquivo:
Tipo de Documento | Extensão do Arquivo | MIME Type |
---|---|---|
AVIF | .avif | image/avif |
BMP | .bmp | image/bmp |
Graphics Interchange Format | .gif | image/gif |
HEIC | .heic | image/heic |
Joint Photographics Experts Group | .jpeg | image/jpeg |
JPEG 2000 | .jp2 | image/jp2 |
JPEG File Interchange Format | .jfif | image/.jfif |
JPG | .jpg | image/jpeg |
JXL | .jxl | image/jxl |
PAM | .pam | image/x-portable-arbitrarymap |
PBM | .pbm | image/x-portable-bitmap |
Portable Document Format | application/pdf | |
Portable Gray Map | .pgm | image/x-portable-graymap |
Portable Network Graphics | .png | image/png |
Portable Pixmap Format | .ppm | image/x-portable-pixmap |
Tagged Image File Format * | .tiff | image/tiff |
WEBP | .webp | image/webp |
:::note
Para arquivos TIFF que possuam mais de uma página, a extração ocorrerá apenas na primeira página.
:::
:::warning
A API aceita como parâmetro de entrada o binário dos arquivos a serem processados, codificado em uma string de texto no padrão base64 conforme a RFC 4648. Da mesma forma, as imagens retornadas nas respostas das rotas serão codificadas em base64 seguindo o padrão RFC 4648.
Para arquivos PDF protegidos por senha, a senha deve ser fornecida em uma string base64 (padrão RFC 4648) e enviada no parâmetro de entrada filePassword
.
:::
Características e limitações dos arquivos de imagem
- O limite máximo de upload do mostQI é de 50MB para PDFs e 20 MB para arquivos em formato de imagens, e com o limite mínimo de área de 5k pixels ou 50 pixels de lado.
- Arquivos PDF que contenham mais de 50 páginas serão recusados. Para arquivos com mais de 5 páginas, deve-se usar a rota assíncrona para evitar timeout.
- Devido à grande variação de qualidade nos dispositivos de captura disponíveis nos smartphones, não há recomendações mínimas em termos de resolução ou tamanho da imagem.
- Para reduzir o tamanho do arquivo a ser enviado para o mostQI, recomenda-se a compressão JPG. Não recomendamos operações de redimensionamento da imagem, pois essa operação pode comprometer a qualidade em grau maior que a compressão JPG.
- Em alguns casos, a compressão com até 80% de perdas é aceitável, mas há uma expressiva redução no tamanho da imagem. A compressão com perdas pode prejudicar o desempenho da leitura, portanto níveis muito altos devem ser usados apenas para imagens muito grandes.
- Imagens que extrapolem o limite superior de 9M pixels serão redimensionadas (de maneira proporcional) para que se encaixem no limite.
Transformação das imagens
A API do mostQI oferece parâmetros opcionais que possibilitam solicitar imagens transformadas com base no arquivo original. Essas imagens são fornecidas na resposta da API em formato base64 (padrão RFC 4648) e estão disponíveis nas seguintes rotas: Content Extraction, VIO Extraction e Smart Invoice Extraction.
Os parâmetros disponíveis são os seguintes:
returnImage
returnImage
: Se este parâmetro for incluído na requisição com o valor 'true', a API retornará recortes dos binários das imagens dos documentos tipificados, corrigindo a perspectiva.
returnedImageQuality
returnedImageQuality
: Permite definir a qualidade da imagem de deskew retornada na rota através do parâmetro returnImage. O valor padrão (quando não informado) é 75.
returnCrops
returnCrops
: Se este parâmetro for incluído na requisição com o valor 'true', a API retornará os recortes dos binários das imagens contidas dentro de um documento tipificado, corrigindo a perspectiva. Esses recortes podem incluir fotos, assinaturas, códigos de barras e impressões digitais. Consulte a lista de documentos lidos para visualizar todos os crops disponíveis.
Resposta padronizada
Todos os métodos da API possuem um corpo de resposta padronizado:
{
"result": {},
"requestId": "",
"elapsedMilliseconds": 0,
"status": {
"message": "Ok",
"code": "200",
"errors": null
}
}
:::warning
A ordem dos elementos dentro do result
não é garantida. É obrigatório utilizar o campo name
como referência para encontrar os valores.
:::
Response
Nome | Tipo | Nulável | Descrição |
---|---|---|---|
result | Variável | Sim | Lista contendo o resultado do método (consulte na documentação específica de cada um). |
requestId | String | Não | Código único de identificação da solicitação ao servidor, que será registrado no histórico de consumo dos serviços. |
elapsedMilliseconds | Integer | Não | Tempo em milissegundos de duração do processamento. |
status | Object | Não | Objeto contendo o código e mensagem de status da resposta. |
Status
Nome | Tipo | Nulável | Descrição |
---|---|---|---|
code | String | Não | Código de status interno. |
message | String | Sim | Mensagem de retorno do status. |
errors | Lista de Error | Sim | Lista de objetos do tipo Error, o formato é variável. |
Contabilização do consumo
As requisições bem-sucedidas serão contabilizadas para fins de faturamento, com diferenciações na forma de contabilização conforme o serviço consumido. Todos os itens faturáveis estão listados no Relatório de Consumo (Consumption Report), devidamente identificados pelo requestId, data e hora da requisição, bem como outros detalhes sobre o resultado do consumo.
Para os serviços que utilizam o recurso de imagem, conforme listados abaixo, haverá a contabilização pela quantidade de documentos processados:
- Content Classification
- Content Extraction
- Content Extraction Async
- Image Properties
- License Plate Recognition
- Multi Page Content Extraction
Documentos tipificados/classificados que retornam resultados de processamento são contabilizados. Além disso, mesmo páginas sem identificação de documentos (páginas em branco) são processadas e contabilizadas. Essas páginas aparecem no Relatório de Consumo com a indicação "utp" (untyped page) na coluna Details.
![](https://api.apidog.com/api/v1/projects/550769/resources/342949/image-preview)Sucesso de extração e faturamento na rota Content Extraction
O status 200 ("message": "Ok", "code": "200") indica sucesso na comunicação com a API e no processamento do arquivo, mas não garante que uma imagem foi identificada no arquivo processado. Caso nenhuma imagem seja reconhecida, o campo "result" retornará vazio, como mostrado no exemplo abaixo:
{
"result": [],
"requestId": "tK6fnYJrxk21T7Mt3OEEb",
"elapsedMilliseconds": 1322,
"status": {
"message": "Ok",
"code": "200",
"errors": null
}
}
O cálculo de consumo e, consequentemente, de cobrança seguem os seguintes critérios para a determinação do volume de imagens processadas:
Imagem de um único documento: Uma requisição REST contendo uma imagem, seja ela tipificada ou não, resulta na contagem de uma imagem processada.
Imagens de múltiplos documentos: Se a requisição REST contiver várias imagens, cada imagem será contabilizada, independentemente de ter sido tipificada ou não. Páginas sem identificação de imagens também são incluídas, pois foram processadas.
:::highlight yellow
⚠️ PONTO DE ATENÇÃO
Para documentos com frente e verso distintos, como RGs e CNHs (não abertas), duas imagens são contabilizadas: uma para a frente e outra para o verso.
- No caso do RG, a extração frente e verso sempre contabiliza duas imagens, mesmo que as imagens sejam capturadas separadamente ou em uma única captura (documento aberto).
- Para a CNH, a contabilização depende da forma de envio:
- CNH aberta: Apenas uma imagem é contabilizada.
- CNH fechada: Duas imagens são processadas, uma para a frente e outra para o verso, gerando a contagem de duas imagens.
:::
Armazenamento de dados e LGPD
O mostQI não armazena as imagens enviadas pelos clientes e todo o processamento ocorre em memória volátil, nos deixando em conformidade com a