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

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.
Cenário 12 1. Requisitante lança um negócio gestor.

2. Requisitante lança os negócios com requisição.

3. Requisitante busca evento de negócio gestor alocado.
Cenário 13 1. Requisitante lança um negócio gestor.

2. Contraparte da gestora lança os negócios com especificação e requisitante busca evento de negócio gestor especificado.
Cenário 14 1. O negócio gestor já foi registrado pela plataforma e requisitante cancela o negócio.
Cenário 15 1. Requisitante lança negócio com especificação e suas ofertas associadas.
Cenário 16 1. O negócio gestor já foi lançado pela plataforma e requisitante busca evento de negócio gestor registrado.

2. Requisitante lança os negócios com especificação associados ao negócio gestor.
Português, Brasil