Manual das Interfaces de Comunicação

O manual fixa requisitos de conexão, mensagens e consumo, separando obrigação de recomendação. Assinatura DICT e prazo de disponibilidade ARQ têm escopos específicos.

• Manual 1.12 detalha ICOM/SPI, DICT e ARQ. SPI cuida de liquidação/Conta PI; DICT de chaves. PSP busca e envia mensagens em APIs BC, sem fornecer servidor HTTP para tráfego ISO 20022. Manual das Interfaces de Comunicação 1.12, p. 4Manual das Interfaces de Comunicação 1.12, p. 6Manual das Interfaces de Comunicação 1.12, p. 8Manual das Interfaces de Comunicação 1.12, p. 29
• Conexão pela RSFN usa HTTP 1.1, TLS 1.2 com autenticação mútua, certificado ICP-Brasil padrão SPB e suporte à suite indicada. Cliente deve respeitar TTL DNS; fixar resolução pode causar indisponibilidade. Canal primário é para expectativa imediata; secundário para data específica sem hora exata. Manual das Interfaces de Comunicação 1.12, p. 7
• Mensagens usam XML UTF-8 e Content-Type apropriado; erro usa application/problem+xml, excepcionalmente text/plain em falha grave. Em 4xx o PSP deve verificar a situação e não submeter a mesma requisição novamente. 5xx deve ser comunicado ao suporte salvo exceção no manual; nem todo 5xx é causado pela API. Manual das Interfaces de Comunicação 1.12, p. 8Manual das Interfaces de Comunicação 1.12, p. 9
• Conexões persistentes são privilegiadas, com Content-Length ou Transfer-Encoding chunked para corpo. Excesso de abertura/conexões simultâneas pode gerar 503. Suporte gzip é obrigatório; uso é recomendado no primário e obrigatório no secundário. Host vai sem porta, mesmo com porta na URL. Manual das Interfaces de Comunicação 1.12, p. 10Manual das Interfaces de Comunicação 1.12, p. 11Manual das Interfaces de Comunicação 1.12, p. 12
• POST /api/v1/in/{ispb}/msgs aceita mensagem avulsa ou multipart/mixed com até dez mensagens, cada parte XML UTF-8. Entrada armazena antes de validar sintaxe/assinatura. 201 confirma gravação para processamento posterior, não liquidação; 4xx não grava, em 5xx a(s) mensagem(s) pode(m) ou não ter sido gravada(s) e, como o SPI é idempotente, o PSP deve tentar o envio novamente quando possível. Manual das Interfaces de Comunicação 1.12, p. 14Manual das Interfaces de Comunicação 1.12, p. 15
• PI-ResourceId identifica armazenamento: novo envio da mesma mensagem gera identificador distinto; entrega repetida ao PSP mantém identificador. Em entrada multipart são separados por vírgulas; saída tem por parte. Não confundir protocolo de armazenamento e identidade funcional do pagamento. Manual das Interfaces de Comunicação 1.12, p. 15Manual das Interfaces de Comunicação 1.12, p. 16
• Limitação por token bucket é por PSP/canal, debitada no processamento, podendo saldo negativo. Saldo esgotado gera 429 com Retry-After em segundos. Parâmetros variam por canal/horário e BC pode alterá-los por participante; classificação correta de prioridade continua necessária. Manual das Interfaces de Comunicação 1.12, p. 17Manual das Interfaces de Comunicação 1.12, p. 18
• PSP inicia saída com GET /api/v1/out/{ispb}/stream/start e deve guardar mensagens antes de seguir PI-Pull-Next da resposta anterior, inclusive 204. Não pode presumir formato desse caminho; pode ser relativo ou absoluto. 200 entrega conteúdo; 204 não tem mensagem, não significa falha. Manual das Interfaces de Comunicação 1.12, p. 19Manual das Interfaces de Comunicação 1.12, p. 20Manual das Interfaces de Comunicação 1.12, p. 21Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 24
• Interromper stream exige DELETE no caminho PI-Pull-Next anterior; sucesso pode ser 200 ou 410. Isso confirma últimas mensagens guardadas e libera recursos. Falha pode causar duplicidade/atraso. Long polling aguarda mensagem ou termina com 204; multipart não espera acumular lote. Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 23Manual das Interfaces de Comunicação 1.12, p. 24Manual das Interfaces de Comunicação 1.12, p. 25
• Recepção pode duplicar mensagens mesmo seguindo caminho correto; ResourceId permite reconhecer. Cada leitura simultânea começa em stream/start. Limite descrito é seis threads por participante/canal, com 429 se excedido. O PSP deve usar o menor tempo possível entre as requisições de leitura; é recomendável apenas armazenar a mensagem e processá-la de forma assíncrona. Manual das Interfaces de Comunicação 1.12, p. 24Manual das Interfaces de Comunicação 1.12, p. 25
• GET /api/v1/in/catalog e GET /api/v1/out/catalog informam versões atuais de mensagens; XML mostrado no manual é exemplo, não catálogo permanente. Manual das Interfaces de Comunicação 1.12, p. 26Manual das Interfaces de Comunicação 1.12, p. 27
• DICT é REST síncrono HTTPS/XML e tem autenticação alinhada ICOM. Requisições são assinadas salvo consulta de chave; todas respostas são assinadas. OpenAPI define endpoints fora deste texto; quickstart público é didático e não deve ser base de integração final. Manual das Interfaces de Comunicação 1.12, p. 28
• ARQ entrega arquivos de SPI/DICT/outros: disponibilidade por vinte e quatro horas após solicitação/criação, depois remoção automática e possível nova solicitação ao SPI. Aceita Range para retomar e cabeçalhos condicionais com ETag/Last-Modified. Essa janela não é prazo geral de retenção do histórico de pagamentos. Manual das Interfaces de Comunicação 1.12, p. 29

O que esta leitura não diz. Não há SLA de app, contrato completo de terceirização, sanção ou catálogo integral de funcionalidades Pix.

Confirmação HTTP de entrada antecede processamento; leitura sem mensagem não é falha. Canais refletem expectativas distintas de horário, e arquivos têm janela própria de disponibilidade.

• Manual 1.12 detalha ICOM/SPI, DICT e ARQ. SPI cuida de liquidação/Conta PI; DICT de chaves. PSP busca e envia mensagens em APIs BC, sem fornecer servidor HTTP para tráfego ISO 20022. Manual das Interfaces de Comunicação 1.12, p. 4Manual das Interfaces de Comunicação 1.12, p. 6Manual das Interfaces de Comunicação 1.12, p. 8Manual das Interfaces de Comunicação 1.12, p. 29
• Conexão pela RSFN usa HTTP 1.1, TLS 1.2 com autenticação mútua, certificado ICP-Brasil padrão SPB e suporte à suite indicada. Cliente deve respeitar TTL DNS; fixar resolução pode causar indisponibilidade. Canal primário é para expectativa imediata; secundário para data específica sem hora exata. Manual das Interfaces de Comunicação 1.12, p. 7
• POST /api/v1/in/{ispb}/msgs aceita mensagem avulsa ou multipart/mixed com até dez mensagens, cada parte XML UTF-8. Entrada armazena antes de validar sintaxe/assinatura. 201 confirma gravação para processamento posterior, não liquidação; 4xx não grava, em 5xx a(s) mensagem(s) pode(m) ou não ter sido gravada(s) e, como o SPI é idempotente, o PSP deve tentar o envio novamente quando possível. Manual das Interfaces de Comunicação 1.12, p. 14Manual das Interfaces de Comunicação 1.12, p. 15
• PI-ResourceId identifica armazenamento: novo envio da mesma mensagem gera identificador distinto; entrega repetida ao PSP mantém identificador. Em entrada multipart são separados por vírgulas; saída tem por parte. Não confundir protocolo de armazenamento e identidade funcional do pagamento. Manual das Interfaces de Comunicação 1.12, p. 15Manual das Interfaces de Comunicação 1.12, p. 16
• Limitação por token bucket é por PSP/canal, debitada no processamento, podendo saldo negativo. Saldo esgotado gera 429 com Retry-After em segundos. Parâmetros variam por canal/horário e BC pode alterá-los por participante; classificação correta de prioridade continua necessária. Manual das Interfaces de Comunicação 1.12, p. 17Manual das Interfaces de Comunicação 1.12, p. 18
• PSP inicia saída com GET /api/v1/out/{ispb}/stream/start e deve guardar mensagens antes de seguir PI-Pull-Next da resposta anterior, inclusive 204. Não pode presumir formato desse caminho; pode ser relativo ou absoluto. 200 entrega conteúdo; 204 não tem mensagem, não significa falha. Manual das Interfaces de Comunicação 1.12, p. 19Manual das Interfaces de Comunicação 1.12, p. 20Manual das Interfaces de Comunicação 1.12, p. 21Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 24
• Interromper stream exige DELETE no caminho PI-Pull-Next anterior; sucesso pode ser 200 ou 410. Isso confirma últimas mensagens guardadas e libera recursos. Falha pode causar duplicidade/atraso. Long polling aguarda mensagem ou termina com 204; multipart não espera acumular lote. Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 23Manual das Interfaces de Comunicação 1.12, p. 24Manual das Interfaces de Comunicação 1.12, p. 25
• Recepção pode duplicar mensagens mesmo seguindo caminho correto; ResourceId permite reconhecer. Cada leitura simultânea começa em stream/start. Limite descrito é seis threads por participante/canal, com 429 se excedido. O PSP deve usar o menor tempo possível entre as requisições de leitura; é recomendável apenas armazenar a mensagem e processá-la de forma assíncrona. Manual das Interfaces de Comunicação 1.12, p. 24Manual das Interfaces de Comunicação 1.12, p. 25
• GET /api/v1/in/catalog e GET /api/v1/out/catalog informam versões atuais de mensagens; XML mostrado no manual é exemplo, não catálogo permanente. Manual das Interfaces de Comunicação 1.12, p. 26Manual das Interfaces de Comunicação 1.12, p. 27
• ARQ entrega arquivos de SPI/DICT/outros: disponibilidade por vinte e quatro horas após solicitação/criação, depois remoção automática e possível nova solicitação ao SPI. Aceita Range para retomar e cabeçalhos condicionais com ETag/Last-Modified. Essa janela não é prazo geral de retenção do histórico de pagamentos. Manual das Interfaces de Comunicação 1.12, p. 29

O que esta leitura não diz. Não há jornada de tela, garantia de pagamento em horário exato ou prazo de retenção geral de histórico.

Integração exige cabeçalhos, formatos, conexão e autenticação prescritos. Consumo encadeia PI-Pull-Next com armazenamento prévio e DELETE; duplicidade e erros exigem tratamentos distintos.

• Manual 1.12 detalha ICOM/SPI, DICT e ARQ. SPI cuida de liquidação/Conta PI; DICT de chaves. PSP busca e envia mensagens em APIs BC, sem fornecer servidor HTTP para tráfego ISO 20022. Manual das Interfaces de Comunicação 1.12, p. 4Manual das Interfaces de Comunicação 1.12, p. 6Manual das Interfaces de Comunicação 1.12, p. 8Manual das Interfaces de Comunicação 1.12, p. 29
• Conexão pela RSFN usa HTTP 1.1, TLS 1.2 com autenticação mútua, certificado ICP-Brasil padrão SPB e suporte à suite indicada. Cliente deve respeitar TTL DNS; fixar resolução pode causar indisponibilidade. Canal primário é para expectativa imediata; secundário para data específica sem hora exata. Manual das Interfaces de Comunicação 1.12, p. 7
• Mensagens usam XML UTF-8 e Content-Type apropriado; erro usa application/problem+xml, excepcionalmente text/plain em falha grave. Em 4xx o PSP deve verificar a situação e não submeter a mesma requisição novamente. 5xx deve ser comunicado ao suporte salvo exceção no manual; nem todo 5xx é causado pela API. Manual das Interfaces de Comunicação 1.12, p. 8Manual das Interfaces de Comunicação 1.12, p. 9
• Conexões persistentes são privilegiadas, com Content-Length ou Transfer-Encoding chunked para corpo. Excesso de abertura/conexões simultâneas pode gerar 503. Suporte gzip é obrigatório; uso é recomendado no primário e obrigatório no secundário. Host vai sem porta, mesmo com porta na URL. Manual das Interfaces de Comunicação 1.12, p. 10Manual das Interfaces de Comunicação 1.12, p. 11Manual das Interfaces de Comunicação 1.12, p. 12
• POST /api/v1/in/{ispb}/msgs aceita mensagem avulsa ou multipart/mixed com até dez mensagens, cada parte XML UTF-8. Entrada armazena antes de validar sintaxe/assinatura. 201 confirma gravação para processamento posterior, não liquidação; 4xx não grava, em 5xx a(s) mensagem(s) pode(m) ou não ter sido gravada(s) e, como o SPI é idempotente, o PSP deve tentar o envio novamente quando possível. Manual das Interfaces de Comunicação 1.12, p. 14Manual das Interfaces de Comunicação 1.12, p. 15
• PI-ResourceId identifica armazenamento: novo envio da mesma mensagem gera identificador distinto; entrega repetida ao PSP mantém identificador. Em entrada multipart são separados por vírgulas; saída tem por parte. Não confundir protocolo de armazenamento e identidade funcional do pagamento. Manual das Interfaces de Comunicação 1.12, p. 15Manual das Interfaces de Comunicação 1.12, p. 16
• Limitação por token bucket é por PSP/canal, debitada no processamento, podendo saldo negativo. Saldo esgotado gera 429 com Retry-After em segundos. Parâmetros variam por canal/horário e BC pode alterá-los por participante; classificação correta de prioridade continua necessária. Manual das Interfaces de Comunicação 1.12, p. 17Manual das Interfaces de Comunicação 1.12, p. 18
• PSP inicia saída com GET /api/v1/out/{ispb}/stream/start e deve guardar mensagens antes de seguir PI-Pull-Next da resposta anterior, inclusive 204. Não pode presumir formato desse caminho; pode ser relativo ou absoluto. 200 entrega conteúdo; 204 não tem mensagem, não significa falha. Manual das Interfaces de Comunicação 1.12, p. 19Manual das Interfaces de Comunicação 1.12, p. 20Manual das Interfaces de Comunicação 1.12, p. 21Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 24
• Interromper stream exige DELETE no caminho PI-Pull-Next anterior; sucesso pode ser 200 ou 410. Isso confirma últimas mensagens guardadas e libera recursos. Falha pode causar duplicidade/atraso. Long polling aguarda mensagem ou termina com 204; multipart não espera acumular lote. Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 23Manual das Interfaces de Comunicação 1.12, p. 24Manual das Interfaces de Comunicação 1.12, p. 25
• Recepção pode duplicar mensagens mesmo seguindo caminho correto; ResourceId permite reconhecer. Cada leitura simultânea começa em stream/start. Limite descrito é seis threads por participante/canal, com 429 se excedido. O PSP deve usar o menor tempo possível entre as requisições de leitura; é recomendável apenas armazenar a mensagem e processá-la de forma assíncrona. Manual das Interfaces de Comunicação 1.12, p. 24Manual das Interfaces de Comunicação 1.12, p. 25
• GET /api/v1/in/catalog e GET /api/v1/out/catalog informam versões atuais de mensagens; XML mostrado no manual é exemplo, não catálogo permanente. Manual das Interfaces de Comunicação 1.12, p. 26Manual das Interfaces de Comunicação 1.12, p. 27
• DICT é REST síncrono HTTPS/XML e tem autenticação alinhada ICOM. Requisições são assinadas salvo consulta de chave; todas respostas são assinadas. OpenAPI define endpoints fora deste texto; quickstart público é didático e não deve ser base de integração final. Manual das Interfaces de Comunicação 1.12, p. 28
• ARQ entrega arquivos de SPI/DICT/outros: disponibilidade por vinte e quatro horas após solicitação/criação, depois remoção automática e possível nova solicitação ao SPI. Aceita Range para retomar e cabeçalhos condicionais com ETag/Last-Modified. Essa janela não é prazo geral de retenção do histórico de pagamentos. Manual das Interfaces de Comunicação 1.12, p. 29

O que esta leitura não diz. Não há algoritmo completo de liquidação, payload de toda mensagem ou valores de bucket imutáveis.

201 indica mensagem armazenada para processamento; 204 indica ausência de mensagem disponível. Canal secundário não oferece hora exata; exemplos de catálogo não são mensagens de interface.

• Manual 1.12 detalha ICOM/SPI, DICT e ARQ. SPI cuida de liquidação/Conta PI; DICT de chaves. PSP busca e envia mensagens em APIs BC, sem fornecer servidor HTTP para tráfego ISO 20022. Manual das Interfaces de Comunicação 1.12, p. 4Manual das Interfaces de Comunicação 1.12, p. 6Manual das Interfaces de Comunicação 1.12, p. 8Manual das Interfaces de Comunicação 1.12, p. 29
• Conexão pela RSFN usa HTTP 1.1, TLS 1.2 com autenticação mútua, certificado ICP-Brasil padrão SPB e suporte à suite indicada. Cliente deve respeitar TTL DNS; fixar resolução pode causar indisponibilidade. Canal primário é para expectativa imediata; secundário para data específica sem hora exata. Manual das Interfaces de Comunicação 1.12, p. 7
• Mensagens usam XML UTF-8 e Content-Type apropriado; erro usa application/problem+xml, excepcionalmente text/plain em falha grave. Em 4xx o PSP deve verificar a situação e não submeter a mesma requisição novamente. 5xx deve ser comunicado ao suporte salvo exceção no manual; nem todo 5xx é causado pela API. Manual das Interfaces de Comunicação 1.12, p. 8Manual das Interfaces de Comunicação 1.12, p. 9
• POST /api/v1/in/{ispb}/msgs aceita mensagem avulsa ou multipart/mixed com até dez mensagens, cada parte XML UTF-8. Entrada armazena antes de validar sintaxe/assinatura. 201 confirma gravação para processamento posterior, não liquidação; 4xx não grava, em 5xx a(s) mensagem(s) pode(m) ou não ter sido gravada(s) e, como o SPI é idempotente, o PSP deve tentar o envio novamente quando possível. Manual das Interfaces de Comunicação 1.12, p. 14Manual das Interfaces de Comunicação 1.12, p. 15
• PI-ResourceId identifica armazenamento: novo envio da mesma mensagem gera identificador distinto; entrega repetida ao PSP mantém identificador. Em entrada multipart são separados por vírgulas; saída tem por parte. Não confundir protocolo de armazenamento e identidade funcional do pagamento. Manual das Interfaces de Comunicação 1.12, p. 15Manual das Interfaces de Comunicação 1.12, p. 16
• PSP inicia saída com GET /api/v1/out/{ispb}/stream/start e deve guardar mensagens antes de seguir PI-Pull-Next da resposta anterior, inclusive 204. Não pode presumir formato desse caminho; pode ser relativo ou absoluto. 200 entrega conteúdo; 204 não tem mensagem, não significa falha. Manual das Interfaces de Comunicação 1.12, p. 19Manual das Interfaces de Comunicação 1.12, p. 20Manual das Interfaces de Comunicação 1.12, p. 21Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 24
• Interromper stream exige DELETE no caminho PI-Pull-Next anterior; sucesso pode ser 200 ou 410. Isso confirma últimas mensagens guardadas e libera recursos. Falha pode causar duplicidade/atraso. Long polling aguarda mensagem ou termina com 204; multipart não espera acumular lote. Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 23Manual das Interfaces de Comunicação 1.12, p. 24Manual das Interfaces de Comunicação 1.12, p. 25
• ARQ entrega arquivos de SPI/DICT/outros: disponibilidade por vinte e quatro horas após solicitação/criação, depois remoção automática e possível nova solicitação ao SPI. Aceita Range para retomar e cabeçalhos condicionais com ETag/Last-Modified. Essa janela não é prazo geral de retenção do histórico de pagamentos. Manual das Interfaces de Comunicação 1.12, p. 29

O que esta leitura não diz. Não há texto obrigatório para tela, layout, SLA de app ou fundamento para mostrar pagamento concluído só por 201.

503 pode resultar de uso de conexões; 429 indica limitação e pode orientar espera. Streams precisam ser finalizados e arquivos ARQ expiram, sem confundir indisponibilidade técnica e estado financeiro.

• Manual 1.12 detalha ICOM/SPI, DICT e ARQ. SPI cuida de liquidação/Conta PI; DICT de chaves. PSP busca e envia mensagens em APIs BC, sem fornecer servidor HTTP para tráfego ISO 20022. Manual das Interfaces de Comunicação 1.12, p. 4Manual das Interfaces de Comunicação 1.12, p. 6Manual das Interfaces de Comunicação 1.12, p. 8Manual das Interfaces de Comunicação 1.12, p. 29
• Conexão pela RSFN usa HTTP 1.1, TLS 1.2 com autenticação mútua, certificado ICP-Brasil padrão SPB e suporte à suite indicada. Cliente deve respeitar TTL DNS; fixar resolução pode causar indisponibilidade. Canal primário é para expectativa imediata; secundário para data específica sem hora exata. Manual das Interfaces de Comunicação 1.12, p. 7
• Mensagens usam XML UTF-8 e Content-Type apropriado; erro usa application/problem+xml, excepcionalmente text/plain em falha grave. Em 4xx o PSP deve verificar a situação e não submeter a mesma requisição novamente. 5xx deve ser comunicado ao suporte salvo exceção no manual; nem todo 5xx é causado pela API. Manual das Interfaces de Comunicação 1.12, p. 8Manual das Interfaces de Comunicação 1.12, p. 9
• Conexões persistentes são privilegiadas, com Content-Length ou Transfer-Encoding chunked para corpo. Excesso de abertura/conexões simultâneas pode gerar 503. Suporte gzip é obrigatório; uso é recomendado no primário e obrigatório no secundário. Host vai sem porta, mesmo com porta na URL. Manual das Interfaces de Comunicação 1.12, p. 10Manual das Interfaces de Comunicação 1.12, p. 11Manual das Interfaces de Comunicação 1.12, p. 12
• POST /api/v1/in/{ispb}/msgs aceita mensagem avulsa ou multipart/mixed com até dez mensagens, cada parte XML UTF-8. Entrada armazena antes de validar sintaxe/assinatura. 201 confirma gravação para processamento posterior, não liquidação; 4xx não grava, em 5xx a(s) mensagem(s) pode(m) ou não ter sido gravada(s) e, como o SPI é idempotente, o PSP deve tentar o envio novamente quando possível. Manual das Interfaces de Comunicação 1.12, p. 14Manual das Interfaces de Comunicação 1.12, p. 15
• PI-ResourceId identifica armazenamento: novo envio da mesma mensagem gera identificador distinto; entrega repetida ao PSP mantém identificador. Em entrada multipart são separados por vírgulas; saída tem por parte. Não confundir protocolo de armazenamento e identidade funcional do pagamento. Manual das Interfaces de Comunicação 1.12, p. 15Manual das Interfaces de Comunicação 1.12, p. 16
• Limitação por token bucket é por PSP/canal, debitada no processamento, podendo saldo negativo. Saldo esgotado gera 429 com Retry-After em segundos. Parâmetros variam por canal/horário e BC pode alterá-los por participante; classificação correta de prioridade continua necessária. Manual das Interfaces de Comunicação 1.12, p. 17Manual das Interfaces de Comunicação 1.12, p. 18
• PSP inicia saída com GET /api/v1/out/{ispb}/stream/start e deve guardar mensagens antes de seguir PI-Pull-Next da resposta anterior, inclusive 204. Não pode presumir formato desse caminho; pode ser relativo ou absoluto. 200 entrega conteúdo; 204 não tem mensagem, não significa falha. Manual das Interfaces de Comunicação 1.12, p. 19Manual das Interfaces de Comunicação 1.12, p. 20Manual das Interfaces de Comunicação 1.12, p. 21Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 24
• Interromper stream exige DELETE no caminho PI-Pull-Next anterior; sucesso pode ser 200 ou 410. Isso confirma últimas mensagens guardadas e libera recursos. Falha pode causar duplicidade/atraso. Long polling aguarda mensagem ou termina com 204; multipart não espera acumular lote. Manual das Interfaces de Comunicação 1.12, p. 22Manual das Interfaces de Comunicação 1.12, p. 23Manual das Interfaces de Comunicação 1.12, p. 24Manual das Interfaces de Comunicação 1.12, p. 25
• Recepção pode duplicar mensagens mesmo seguindo caminho correto; ResourceId permite reconhecer. Cada leitura simultânea começa em stream/start. Limite descrito é seis threads por participante/canal, com 429 se excedido. O PSP deve usar o menor tempo possível entre as requisições de leitura; é recomendável apenas armazenar a mensagem e processá-la de forma assíncrona. Manual das Interfaces de Comunicação 1.12, p. 24Manual das Interfaces de Comunicação 1.12, p. 25
• GET /api/v1/in/catalog e GET /api/v1/out/catalog informam versões atuais de mensagens; XML mostrado no manual é exemplo, não catálogo permanente. Manual das Interfaces de Comunicação 1.12, p. 26Manual das Interfaces de Comunicação 1.12, p. 27
• DICT é REST síncrono HTTPS/XML e tem autenticação alinhada ICOM. Requisições são assinadas salvo consulta de chave; todas respostas são assinadas. OpenAPI define endpoints fora deste texto; quickstart público é didático e não deve ser base de integração final. Manual das Interfaces de Comunicação 1.12, p. 28
• ARQ entrega arquivos de SPI/DICT/outros: disponibilidade por vinte e quatro horas após solicitação/criação, depois remoção automática e possível nova solicitação ao SPI. Aceita Range para retomar e cabeçalhos condicionais com ETag/Last-Modified. Essa janela não é prazo geral de retenção do histórico de pagamentos. Manual das Interfaces de Comunicação 1.12, p. 29

O que esta leitura não diz. Não há SLA interno, regra de repetir qualquer erro ou retenção geral de pagamentos por vinte e quatro horas.