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.
Undefined