> For the complete documentation index, see [llms.txt](https://portal-integracao.intelbras.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://portal-integracao.intelbras.com.br/linha-de-faciais/introducao/introducao.md).
# Inicio
Bem-vindo à documentação da API da linha de acesso da Intelbras. Esta API tem como objetivo fornecer informações e orientações sobre como integrar com os dispositivos de acesso da Intelbras.
Nossos equipamentos de acesso possuem uma interface de comunicação baseada em TCP/IP (Ethernet), tornando a integração simples e independente do sistema operacional e da linguagem de programação utilizados. Neste documento, você encontrará todos os detalhes necessários para utilizar a API e integrar facilmente com nossos dispositivos de acesso.
### **Dispositivos da Linha Bio-T que suportam a API:**
| Dispositivos | Suporta API? |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| SS 5520 | ✅ |
| SS 5530 MF FACE | ✅ |
| SS 5530 MF FACE LITE | ✅ |
| SS 3530 MF FACE W | ✅ |
| SS 3430 BIO | ✅ |
| SS 3430 MF BIO | ✅ |
| SS 7520 FACE T | ✅ |
| SS 7530 FACE | ✅ |
| SS 3530 MF FACE | ✅ |
| SS 3540 MF FACE EX | ✅ |
| SS 1540 MF W | ✅ |
| SS 1530 MF W | ✅ |
| SS 3540 MF FACE BIO EX | ✅ |
| SS 3540 MF FACE BIO | ✅ |
| SS 3532 MF W | ✅ |
| SS 3532 MF | ✅ |
| SS 3542 MF W | ✅ |
| SS 3531 MF | ✅ |
| SS 5531 MF W | ✅ |
| SS 5541 MF W | ✅ |
| SS 5532 MF W | ✅ |
| SS 5542 MF W | ✅ |
| SS 5430 MF BIO FT | ✅ |
| SS 3541 MF | ✅ |
| SS 3420 BIO | ❌ |
| SS 3420 MF BIO | ❌ |
| CT 3000 4PB/2PB | Documentação - CT 3000 2PB/4PB |
| SS 3710 UHF | Documentação - SS 3710 UHF |
| CT 5000 4PB | Documentação - CT 5000 4PB |
### Padrão de Sintaxe Utilizada
A sintaxe da API deve seguir o padrão de **URI** (RFC 3986 Uniform Resource Identifiers).
**protocolo**: Valor padrão suportado pela API é o "http". Existem exceções apenas em algumas chamadas RTSP que usando o valor "RTSP".
**servidor**: O servidor é definido por "hostname:porta". O nome do host pode ser o endereço IP ou o nome de domínio de um dispositivo IP. A porta é o número da porta de conexão TCP configurada no dispositivo. Se a porta não for configurada, a porta **80** utilizada.
**abs\_path**: O Request-URI para os recursos é abs\_path. O abs\_path nesta especificação é na maioria das vezes "/cgi-bin/\*.cgi".
**query**: O campo query é uma string de informações a ser interpretada pelo dispositivo. Consiste em parâmetros relacionados ao recurso sendo requisitado. Deve ser informado seguindo a sintaxe nome=valor. Por exemplo: channel=1 ()
### Formato de respostas
O servidor usa os códigos de status **HTTP** padrão. Com o seguinte código **HTTP** e significados:
Se o código HTTP for **200**, significa que a API foi executada com sucesso e os dados de resposta no corpo HTTP (multipart) pode ser uma multiline **key=value** de valor ou um objeto JSON ou apenas uma linha com uma palavra ***"OK"***
Alguns dispositivos em suas versões mais recentes, podem retornar no corpo da resposta a requisição alguns códigos de erro verifique a página Códigos de Erros de Requisição
### Autenticação
Os dispositivos possuem suporte digest authentication, consulte **RFC 2617** (RFC 2617 HTTP Authentication)
A autenticação Digest é um esquema de autenticação baseado em desafio-resposta que permite que um cliente se autentique com um servidor web protegido por senha.
Quando um cliente faz uma solicitação HTTP para um recurso protegido por autenticação Digest, o servidor web responde com um código de status HTTP 401, indicando que o acesso não é permitido sem autenticação. Junto com o código de status 401, o servidor também envia um cabeçalho "WWW-Authenticate" contendo informações sobre a proteção utilizada para a senha, bem como um desafio aleatório.
O cliente responde ao desafio enviando um cabeçalho "Authorization" contendo as credenciais de autenticação criptografadas, juntamente com informações sobre o desafio e outras informações necessárias. O servidor web verifica se as credenciais estão corretas e, se estiverem, retorna um código de status HTTP 200, indicando que o acesso ao recurso foi permitido.
O motivo pelo qual o servidor web envia um código de status HTTP 401 antes de enviar o código de status HTTP 200 é que o cliente precisa ser informado de que a autenticação é necessária antes de enviar as credenciais de autenticação criptografadas. O código de status HTTP 401 é usado para indicar que o acesso ao recurso é negado sem autenticação.
Em resumo, a sequência de códigos de status HTTP 401 seguido por um código de status HTTP 200 é um comportamento padrão na autenticação Digest para permitir que o cliente se autentique com o servidor web protegido por senha
Se a solicitação HTTP enviada pelo cliente não fornecer informações de cabeçalho de "authorization" válidas, o dispositivo retorna o código de status \*\*HTTP 401\*\*.
Exemplo de Autenticação:
{% tabs %}
{% tab title="Python" %}
```python
device_ip = '192.168.1.201'
username = 'admin'
password = 'admin12345'
url = "http://{}/cgi-bin/global.cgi?action=getCurrentTime".format(
str(ip)
)
digest_auth = requests.auth.HTTPDigestAuth(username, passwd)
rval = requests.get(url, auth=digest_auth, timeout=20, verify=False)
```
{% endtab %}
{% tab title="Javascript" %}
```javascript
const url = 'http://192.168.3.87/cgi-bin/accessControl.cgi?action=openDoor&channel=1';
const username = 'admin';
const password = 'acesso1234';
const auth = 'Digest ' + Buffer.from(`${username}:${password}`).toString('base64');
request({
url: url,
headers: {
'Authorization': auth
},
auth: {
username: username,
password: password,
sendImmediately: false
}
}, function(error, response, body) {
if (error) {
console.error(error);
} else {
console.log(body);
}
});
```
{% endtab %}
{% endtabs %}
### Bibliotecas Postman
Recomendamos a execução das chamadas de teste da API utilizando um software client rest como [Insomnia](https://insomnia.rest) ou [Postman](https://www.postman.com) antes de encapsular em seu software.
Para facilitar a integração foi realizado o mapeamento das principais chamadas na ferramenta Postman, possibilitando importar as chamadas e realizar os testes, disponível através do link: [**DOWNLOAD POSTMAN COLLECTIONS**](https://drive.google.com/file/d/1X-wFuwzf1tjJRNYFTbwH9qFRAECYAY8e/view?usp=sharing)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://portal-integracao.intelbras.com.br/linha-de-faciais/introducao/introducao.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.