Detalhamento técnico - Ambiente Sandbox
Este documento apresenta todos os requisitos técnicos necessários para conectividade da instituição financeira à plataforma de Pre-matching no ambiente de Sandbox.
O que é um ambiente de sandbox?
Sandbox é um ambiente de computação controlado e limitado, que ajuda a validar e integrar novas funcionalidades e fluxos de sistemas de forma segura. Com ele, você pode testar cenários específicos sem afetar as suas contas reais de produção ou homologação.
Conectividade
- Para ter acesso à API do Pre-matching no ambiente sandbox, você precisa apenas de a internet e realizar um cadastro prévio aqui neste portal de desenvolvedores (Selic Conecta).
- A plataforma do Pre-matching neste ambiente de sandbox permite acesso exclusivamente através de HTTP REST API.
- Todas as solicitações à API devem ser realizadas através de conexão HTTPS com TLS 1.2.
- O acesso através de HTTP REST API exige um “client_id” e uma chave de acesso chamado de “client_secret”. Cada usuário interessado em obter um acesso ao sandbox deverá se cadastrar previamente neste portal e criar um APP (Que significa obter seu “client_id” e sua chave de acesso “client_secret”.
Regras de firewall
Ambiente | URL | IPs |
---|---|---|
Sandbox | https://api.sandbox.selic.gov.br/ | 52.67.58.80 e 18.228.37.51 |
Acessando através da API
O acesso à API da plataforma de Pre-matching exige a obtenção de um “client_id” e um “client_secret”.
Estes dados podem ser acessados diretamente por cada usuário interessado em utilizar o sandbox através do Selic Conecta.
Após ter realizado seu cadatro aqui na plataforma, validar seu email e realizar login na plataforma, acesse a opção do menu "Ferramentas da API" e depois escolha "Minhas Apps". Cadastre um novo APP e obtenha suas credenciais.
Abaixo segue algumas figuras apresentando a tela deste acesso:


Autenticação à API
O método de autenticação disponível na API da plataforma de Pre-matching no Sandbox é o OAuth2 e HTTP padrão através de TOKEN JWT.
Para iniciar a comunicação com a plataforma e acessar as URLs protegidas da plataforma você necessitará recuperar um token de acesso válido.
Nas seções seguintes seguem alguns exemplos utilizando a aplicação cURL para o envio da requisição autenticada para exemplificar a solicitação de um token.
Nota: cURL é um aplicativo open source e não é suportado pelo Selic. Ele é citado apenas para demonstração das chamadas HTTP.
Recuperação/Solicitação de um token JWT para uso na API.
As variáveis são identificadas por ${}. Exemplo: ${client_id} é a variável que identifica o cliente da API da sua instituição, como por exemplo "desenv" nos ambientes de desenvolvimento. Ex
curl -X POST \ https://api.sandbox.selic.gov.br/auth/realms/logon/protocol/openid-connect/token \ -H 'Accept: */*' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -H 'Host: api.sandbox.selic.gov.br' \ -d 'grant_type=client_credentials&client_id=${client_id}&client_secret=${client_secret}'
Simulação de envio (Request)
curl -X POST \ https://api.sandbox.selic.gov.br/auth/realms/logon/protocol/openid-connect/token \ -H 'Accept: */*' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -H 'Host: api.sandbox.selic.gov.br' \ -d 'grant_type=client_credentials&client_id=desenv&client_secret=secret'
Simulação de comunicação à API
Após recuperação do TOKEN válido, você deve utilizá-lo nas chamadas à API, seguindo o exemplo abaixo
curl -X GET \ https://api.sandbox.selic.gov.br/pre-matching/api/v2/negocios/202004010000001 \ -H "accept: application/json" \ -H 'Authorization: Bearer eyJhbGciOiJ...ctSsFxQ' \ -H 'Host: api.sandbox.selic.gov.br'
Rate Limiting – Limitação de requisições
A política de limitação (rate-limiting) funciona com base em cabeçalhos enviados na requisição. Todas as requisições de consulta, geração e atualização de TOKENS serão limitadas.
Portanto, atente-se a configuração do seu cliente da API evitando bloqueios de acesso à plataforma causada por excesso de requisições.
Inicialmente a pltaforma permitirá até 100 requisições por minuto.
As respostas do cabeçalho HTTP de qualquer requisição à API mostrarão o status atual do seu limite de requisições permitidas. Exemplo:
curl -X GET \ https://api.sandbox.selic.gov.br/pre-matching/api/v2/negocios/202004010000001 \ -H "accept: application/json" \ -H 'Authorization: Bearer eyJhbGciOiJ...ctSsFxQ' \ -H 'Host: api.sandbox.selic.gov.br' HTTP/1.1 200 OK Date: Mon, 13 Jul 2020 09:27:06 GMT Status: 200 O RateLimit-Limit: 100 RateLimit-Remaining: 10 RateLimit-Reset: 60
Descrição:
RateLimit-Limit = O número máximo de requisições por minuto.
RateLimit-Remaining = O número de requisições restantes dentro da janela de limite atual.
RateLimit-Reset = O tempo em que o limite de requisições atual será reiniciado. (Em segundos).
Caso sua aplicação cliente exceda este limite, ela receberá um HTTP STATUS 429 informando que o limite máximo permitido foi ultrapassado. Exemplo:
GET /obter-status/123 Response: HTTP/1.1 429 Too Many Requests Content-Type: application/json Date: Mon, 13 Jul 2020 09:27:40 GMT Retry-After: Mon, 13 Jul 2020 09:27:40 GMT RateLimit-Limit: 100 Ratelimit-Remaining: 0 RateLimit-Reset: 60 { "title": "Too Many Requests", "status": 429, "detail": "Você ultrapassou o número de requisições permitidas" }
Dica: Você pode adequar seu cliente de API para que verifique cada requisição os campos RateLimit-Limit ou Ratelimit-Remaining enviados no cabeçalho HTTP das respostas evitando o bloqueio temporário na plataforma.
Cenários de testes disponíveis (Mock)
Nem todas as funcionalidades se encontram disponíveis neste ambiente de sandbox. Abaixo você encontra todos os cenários possíveis de serem testados e detalhes de como eles devem ser realizados.
Clique aqui para efetuar o download da collection para o Postman com os cenários disponíveis (As requisições precisam ser idênticas aos exemplos contidos nas coleções. Caso contrário, as respostas retornarão erro HTTP). Todos os cenários utilizam o iSelic 95959595 como requisitante.
Cenário | Descrição |
---|---|
Cenário 1 | 1. Requisitante realiza o lançamento do negócio e aguarda a correspondência pela contraparte |
Cenário 2 | 1. Requisitante realiza o lançamento do negócio já lançado pela contraparte |
Cenário 3 | 1. Requisitante realiza o lançamento do negócio inválido |
Cenário 4 | 1. Contraparte já efetuou o lançamento do negócio e requisitante recebe "negócio lançado" ao buscar eventos 2. Requisitante efetua o lançamento da segunda ponta do negócio 3. Requisitante recebe "negócio registrado" ao buscar eventos 4. Requisitante registra uma requisição de especificação sem quebra 5. Contraparte registra a requisição de especificação sem quebra e requisitante recebe "requisição especificação lançada", "especificação criada" com status "especificação completa" 6. Requisitante confirma a especificação 7. A contraparte confirma e requisitante recebe "comando gerado credito" ao buscar eventos |
Cenário 5 | 1. Requisitante efetua o lançamento da primeira ponta do negócio 2. Requisitante envia uma lista com 3 requisições de especificação para o negócio 3. Contraparte registra o negócio, envia a requisição sem quebra e o requisitante recebe "negócio registrado" e três "especificação criada" com status "especificação completa" ao buscar eventos 4. Contraparte altera o PU de uma das especificações e requisitante recebe "especificação alterada" com status "em especificação" ao buscar eventos 5. Requisitante busca a especificação e recebe situação do atributo PU divergente 6. Requisitante altera a especificação considerando o mesmo PU informado pela contraparte e recebe como resposta uma "especificação completa" 7. Requisitante confirma a especificação alterada 8. A contraparte confirma e requisitante recebe "especificação aguardando confirmação cessionário", "especificação confirmada" e "comando gerado debito" ao buscar eventos * Os outros comandos serão gerados a medida que as especificações forem confirmadas |
Cenário 6 | 1. Requisitante efetua o lançamento da primeira ponta do negócio 2. Requisitante passa dois latros para o négócio, enviando duas requisições de especificação 3. Contraparte registra o negócio, envia as requisições referentes a cada lastro e o requisitante recebe "negócio registrado" e duas "especificação criada" com status "especificação completa" ao buscar eventos 4. Requisitante confirma as duas especificações 5. A contraparte confirma e requisitante cedente conclui negócio 6. Requisitante recebe "especificação aguardando confirmação cessionário", "especificação confirmada" e "comando gerado debito" para cada especificação ao buscar eventos |
Cenário 7 | 1. Bacen efetua o lançamento do negócio do leilão, informa os lastros e requisitante recebe "negócio registrado" e "requisição especificação lançada" ao buscar eventos 2. Requisitante passa dois latros para o négócio, enviando duas quebras de requisição de especificação 3. Requisitante recebe dois "especificação criada" ao buscar eventos e confirma as duas especificações 4. A contraparte confirma as especificações e conclui negócio 5. Requisitante recebe "especificação aguardando confirmação cedente", "especificação confirmada" e "comando gerado credito" para cada especificação ao buscar eventos |
Cenário 8 | 1. Contraparte já efetuou o lançamento do negócio e requisição de especificação simultaneamente e requisitante recebe "negócio lançado" com atributo batimentoComConta verdadeiro ao buscar eventos 2. Requisitante efetua o lançamento da segunda ponta do negócio 3. Requisitante recebe "negócio registrado" e "especificação criada" com status "especificação completa" ao buscar eventos 4. Requisitante confirma a especificação 5. A contraparte confirma e requisitante recebe "comando gerado credito" ao buscar eventos |
Cenário 9 | 1. Os negócios da ponta da Tesouraria e do Custodiante já foram lançados. 2. A Corretora lança o negócio de venda e recebe "negócio registrado." 3. As requisições de especificações são criadas, e a especificação é confirmada. 4. A Corretora lança o negócio de compra e recebe "negócio registrado." 5. As requisições de especificações são criadas, e a especificação é confirmada. 6. A Corretora associa os negócios." 7. A Corretora busca negócio com a Tesouraria, com id lote. 8. As operações do lote são liquidadas no Selic 9. A corretora busca Evento de lote liquidado. |
Cenário 10 | 1. Os negócios já foram lançados e tem pelo menos um comando gerado, sendo configurado como intermediação em lote. 2. Tesouraria busca evento de autorização do negócio disponível com id lote. 3. A tesouraria autoriza o envio automático ao Selic. 4. A Corretora lança no Selic. 5.O Pre Matching lança comando da tesouraria automaticamente. 6.Tesouraria recebe evento de lote liquidado. | Cenário 11 | 1. Os negócio da Tesouraria e do Custodiante já forma lançados. 2. A Corretora lança os negócios e associa. 3. Corretora busca negócio com Tesouraria com id lote. 4. O Custodiante informa a Corretora que desistiu da operação. 5. Corretora aloca a especificação em conta própria 6. Corretora busca evento de comando de crédito e débito gerados com a conta própria 7. A Corretora busca negócio com a Tesouraria, com ID do lote. 8. As operações do lote são liquidadas no Selic 9. A corretora busca Evento de lote liquidado. |