Table of Contents

Integração via API REST

1. Âmbito

O API REST do ilink permite um controlo programático das principais operações de documentos presentes no ilink, facilitando a integração com programas externos.

O ilink distingue 2 fluxos principais de integração: receção e emissão de documentos, dos quais poderão ser implementados ambos ou apenas um, dependendo das necessidades do software a integrar.

2. Notas Técnicas

Nota: Os documentos emitidos e recebidos via API podem ser consultados no portal de testes do ilink usando as credenciais que vos foram enviadas.

3. Pré requisitos

De modo a integrar via API, será necessário primeiro entrar em contacto com a nossa equipa (apoio@ilink.pt) de modo a pedir acessos ao nosso ambiente de testes/qualidade.

Os acessos disponibilizados serão os seguintes:

Isto significa que cada cliente que permite emitir ou receber documentos necessita de um pré-registo com a nossa equipa, de modo a ser gerada a sua chave pública. O token de plataforma será único para o sistema a integrar (comum a todos os clientes que utilizam o vosso sistema), e deverá ser usado em todas as chamadas ao API.

Nos acessos de teste, também são disponibilizados 2 clientes/NIFs, juntamente com os seus logins de acesso ao portal do ilink. Deverão usar estas entidades para transacionar documentos entre si, e opcionalmente aceder ao portal para consulta dos mesmos. Os NIFs atribuídos podem ser alterados se necessário.

Nota: Serão enviados novos acessos (token de plataforma e chave pública por NIF) mediante entrada em produção.

4. Especificação técnica

Aceder à especificação swagger

O ilink utiliza uma especificação OpenApi 3, e está disponível aqui. Neste cliente web, poderá efetuar chamadas de teste ao nosso API, analisar as respostas obtidas bem como os dados a enviar para cada endpoint/método.

O cliente swagger disponibilizado acima deverá acompanhar o vosso processo de desenvolvimento. É também possível verificar como as chamadas ao API são construídas via cURL (ver exemplo abaixo):

img info

Nota: São também disponibilizados vários clientes HTTP, em mais de 50 linguagens e frameworks (Java, C#, .NET, PHP, NodeJS, etc.), gerados automaticamente a partir da nossa especificação, que poderão servir de suporte inicial ao processo de integração.

4.1 Autorização

Todos os pedidos a efetuar ao API têm de conter obrigatoriamente o header de autorização: Authorization: Bearer <TOKEN_PLATAFORMA>

No cliente Swagger, o processo é feito inserindo o token de plataforma após clicar no botão Authorize

img info

Após esta operação, deverão notar que todos os pedidos subsequentes ao API incluem o header Authorization:

img info

4.2 Autenticação

Antes de efetuar a primeira consulta ao API do ilink, é obrigatório efetuar uma autenticação por cliente/NIF. Esta autenticação serve de handshake inicial entre o cliente e o ilink é feita com recurso ao endpoint POST /apps/authentications:

img info

Uma autenticação válida deverá retornar esta resposta: 

HTTP status: 200 OK
 
{
	success: true,
	message:{
		code:"e123",
		msg:"Integração realizada com sucesso."
	}
}

A autenticação tem duração ilimitada (só precisa de ser invocada 1 vez por cliente/NIF que acede ao API). Pode também ser revogada através do método DELETE /apps/authentications:

img info

Se o processo de autenticação não for concluído, ou o header Authorization não for enviado nos pedidos ao API, todas as chamadas serão recusadas para esse NIF com um erro: 

HTTP status: 401 Unauthorized
 
{  
	success: false,  
	errors: [{  
		code: "e069",  
		msg: "Autenticação inválida" 
	}]  
}

Nota: Em ambiente de produção é necessário autenticar novamente cada cliente/NIF.

5. Emissão de documentos

5.1 Âmbito

Permite à plataforma integradora emitir documentos no ilink, que são posteriormente enviados para o seu destinatário. O destinatário dos documentos tem configurado no portal do ilink para que sistemas externos os documentos devem ser remetidos. Isto significa que o processo de envio de documentos aos ERP's e EDI's adequados de cada cliente é transparente ao API e fica à responsabilidade do ilink. Estas configurações são efetuadas pela equipa de apoio do ilink.

A plataforma ilink permite o envio de faturas eletrónicas em 2 cenários distintos:

Como são enviados os documentos para outros brokers EDI? Na fase de passagem a produção, deverá ser feito um levantamento de todas as entidades que irão receber documentos via EDI, bem como os seus brokers EDI em uso. De seguida, a equipa de apoio (apoio@ilink.pt) irá configurar as ligações necessárias de modo a que os documentos sejam integrados automaticamente no sistema de cada recetor. Antes de enviar documentos para a solução FE-AP da eSPap, será também necessário cada emissor de faturas completar o processo de adesão de fornecedores FE-AP.

Todos os documentos emitidos ficam disponíveis no portal do ilink tanto na entidade emissora como na entidade recetora dos mesmos.

Nota: No nosso ambiente de testes, devem emitir documentos apenas entre as 2 entidades que receberam acessos. Caso pretendam verificar o funcionamento do envio de documentos para um consumidor final (NIF arbitrário), deverão sempre emitir o mesmo por uma das entidades que receberam acessos.

IMPORTANTE: Para a emissão de documentos a entidades públicas, recomendamos fortemente implementar os seguintes pontos, sob pena de não integrar os documentos com certos sistemas:

5.2 Assinatura digital

O ilink permite assinar automaticamente os anexos dos documentos emitidos na plataforma (XML e PDF), desde que a entidade emissora tenha adquirido e configurado o selo de um dos provedores de assinaturas digitais qualificadas. Neste momento, apenas o GTS - Global Trusted Sign é suportado, mas existem planos de suportar os restantes provedores em Portugal (Multicert e DigitalSign).

Isto significa que o ERP não é obrigado a integrar com um provedor de assinaturas, deixando (opcionalmente) o processo de certificação à responsabilidade do ilink. A outra alternativa será o próprio ERP efetuar o processo de certificação e enviar os documentos previamente assinados para o ilink.

Nota: No caso de assinatura via ilink, todos os ficheiros resultantes serão assinados no momento de entrada (xml e pdf), e só depois remetidos ao cliente. Este processo é configurado no portal web, ficando fora da responsabilidade do API.

No caso de assinatura via ERP, a assinatura digital do documento será validada a nível criptográfico para todos os documentos que entram no sistema, e um documento com assinatura inválida, tanto no XML como no PDF irá retornar sempre um erro via API como o seguinte: 

HTTP status: 400 Bad request
 
{
	success:  false,
	errors:{
		document:{
			code: "e217", 
			msg: "A assinatura do documento não é válida."
		}
	}
}

O erro anterior indica que o documento sofreu alterações desde o momento que foi assinado, ou que a assinatura do mesmo foi gerada incorretamente. O seguinte validador pode ser utilizado para verificar a validade da assinatura dos documentos. Os formatos de assinatura reconhecidos pelo ilink são PADES e PKCS7-B (PDF), ou XMLDSig e XADES-BES (XML).

Nota: Os requisitos legais de assinatura das faturas eletrónicas estão disponíveis no Decreto-Lei 28/2019, secção II, artigo 12º.

Nota: O ilink assina os documentos PDF em PADES e os documentos XML em XADES-BES enveloped.

5.3 Métodos de envio

Após efetuada a autenticação com sucesso, estamos em condições de começar a enviar documentos. O API do ilink possibilita 2 métodos de envio de documentos:

a) Envio do XML em formato UBL 2.1 CIUS-PT (ou UBL 2.1 PEPPOLBIS3 - Encomendas)

Neste método, o sistema a integrar tem de gerar corretamente o ficheiro XML antes de enviar o mesmo ao ilink. Todos os ficheiros XML enviados por este método são verificados de acordo com o validador oficial da eSPap, versão 2.1.2, e o API irá retornar um erro caso se verifiquem inconsistências sintáticas. A eSPap disponibiliza um validador Schematron que implementa todas as validações da Norma Europeia EN16931 CIUS e as validações adicionais do CIUS-PT, e está disponível online neste link. Se os ficheiros validam sintaticamente no validador online, então deverão validar no ilink.

Nota: Para incluir um ficheiro PDF e outras situações habituais, consultar a secção casos de uso.

Nota: Podem consultar vários exemplos, bem como toda a especificação do CIUS-PT aqui.

Ver casos de uso

Alguns exemplos de erros no processo de validação XML: 

HTTP status: 400 Bad request
 
{
	success: false,
	errors:{
		document:{
			code:"e217",
			msg:"[BR-CO-25]-Caso o valor a pagar (BT-115) seja positivo, deve indicar a data de vencimento (BT-9) ou a nota da condição de pagamento (BT-20)."
		}
	}
}
HTTP status: 400 Bad request
 
{
	success: false,
	errors:{
		document:{
			code:"e217",
			msg:"[DT-CIUS-PT-166]-Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114), with an acceptance range of 1.00 € (it does not mean that this tolerance is accepted by the customer)."
		}
	}
}

O método a utilizar para envio do XML é o POST /apps/documentsUBL. Neste contexto, a chave pública identifica o emissor do documento e tem de ser a chave associada ao NIF do emissor do documento especificado no XML (AccountingSupplierParty>Party>PartyTaxScheme>CompanyID para faturas/notas de crédito, ou AccountingCustomerParty>Party>PartyTaxScheme>CompanyID para encomendas). Caso isto não se verifique, o API irá retornar o seguinte erro: 

HTTP status: 400 Bad request
 
{
	success: false,
	errors:{
		supplier:{ 
			code:"e199",
			msg:"A entidade criadora do documento deve ser cliente ou fornecedor do novo documento."
		}
	}
}

Se o XML for válido e respeitar todas as validações XML, bem como regras de negócio adicionais do recetor, o API devolve uma resposta de sucesso, juntamente com os dados principais do documento criado: 

HTTP status: 201 Created
 
{
	success: true,
	message:{
		code:"s011",
		msg:"Documento criado com sucesso"
	},
	response:{
		data:{
			id:"60796c3c2a6fa2.53909016",
			number:"7411111",
			emission_date:"2021-04-15",
			type_document_fact:{
				id:"5c9cb870a5ef57.36583702",
				code:"380",
				alias:"invoice",
				type:"FT",
				description:"Fatura"
			},
			type_document:{
				alias:"issued",
				description:"Emitido"
			},
			state_document:{
				id:"5c9cb878745b16.4225687",
				alias:"sent",
				description:"Enviado ao cliente."
			}
		}
	}
}

Nota: Um documento é enviado com sucesso ao destinatário via EDI quando o campo state_document.alias tem o valor sent ou accepted. Caso se apenas pretenda que o documento seja enviado via e-mail, o estado do documento deve ser ignorado, e devemos consultar os e-mails enviados através da consulta de estado do mesmo.

b) Envio dos dados estruturados do documento

Ao adotar esta opção, o ERP dispensa de efetuar a geração completa do XML, ficando assim o ilink responsável por gerar o XML final. Assim, o ERP apenas necessita de enviar ao ilink todos os dados referentes ao documento. O endpoint a adotar aqui será o POST /apps/documents

img info

A especificação deste método é extensa, pois cobre todos os campos possíveis de um fatura/encomenda, que estão devidamente documentados acima. Todos os documentos criados por este endpoint estão sujeitos às mesmas validações que os documentos enviados pelo método POST /apps/documentsUBL, ou seja, o XML resultante dos dados inseridos será validado de acordo com o validador oficial da eSPap, que pode ser consultado online neste link, e segundo as regras de negócio adicionais do recetor do documento, caso existam.

Nota: Para incluir um ficheiro PDF e outras situações habituais, consultar a secção casos de uso.

Nota: É possível enviar vários anexos num documento através do campo files[] (ver especificação acima). Contudo, a representação visual do documento (i.e PDF original da fatura usado na impressão) deve ser enviado sempre no campo file, sendo o campo files[] reservado para ficheiros adicionais (notas de encomenda, avisos de despacho, guias de transporte, etc.). Se o emissor do documento tem uma assinatura digital ativa no ilink, todos os anexos serão assinados.

5.4 Envio do documento

5.4.1 Envio via EDI

Um documento, após criação com sucesso (HTTP status 200) por qualquer um dos métodos acima (envio de XML ou envio de dados), será enviado automaticamente ao destinatário por EDI. Contudo, em casos pontuais, este poderá não ser entregue imediatamente ao destinatário via EDI devido a configurações em falta e/ou outras anomalias na plataforma ilink ou no sistema do recetor. Caso isto se verifique, será devolvido um campo to_send_status na resposta do documento a detalhar a situação: 

HTTP status: 200 OK
 
{
	success: true,
	message:{
		code:"s011",
		msg:"Documento criado com sucesso"
	},
	response:{
		data:{
			id:"60796c3c2a6fa2.53909016",
			state_document:{
				id:"5c9cb870f34b16.42025494",
				alias:"tosend",
				description:"Por enviar ao cliente."
			},
			to_send_status:{
				code: "sent_connection", 
				title: "Aguardar a aceitação de ligação com o destinatário do documento."
			}
		}
	}
}

Nota: Pode-se verificar que o documento NÃO foi entregue via EDI pois o campo state_document.alias assume o valor 'tosend'.

Os motivos possíveis (code) para um documento não ser entregue são:

Após regularizar a situação de erro, será possível enviar o documento novamente (ver secção de reenvio de documentos).

Nota: O estado do documento é apenas aplicável a envios EDI. Caso o documento seja enviado para um cliente arbitrário via e-mail (PDF), o estado de envio (state_document) não reflete o envio do e-mail (ver seção seguinte).

5.4.2 Envio via e-mail

Um documento, após criação com sucesso (HTTP status 200) por qualquer um dos métodos acima (envio de XML ou envio de dados), será remetido via e-mail ao destinatário caso seja especificado o campo send_by_email com o valor 1. O(s) endereço(s) do(s) recetor(es) do documento pode(m) ser especificado(s) de 3 modos:

Para consultar o envio dos e-mails e leitura dos mesmos para o cliente, ver secção b) de consulta de estado de documentos emitidos.

5.4.3 Criação de documentos e consumo de assinaturas digitais qualificadas

Esta secção é apenas relevante para clientes que utilizam o ilink para assinar digitalmente os documentos. (ver detalhes)

Caso esteja configurada uma assinatura digital qualificada no ilink, todos os documentos serão assinados no momento da sua criação, incluindo todos os ficheiros resultantes (xml e pdf). Dado que a assinatura dos documentos não é obrigatória por lei em todos os cenários de utilização, é possível controlar individualmente a assinatura dos ficheiros xml e pdf no momento da criação do documento com recurso aos os campos disable_xml_sign e disable_pdf_sign. Isto permite reduzir o consumo de assinaturas, bem como otimizar o processo de criação de documentos.

Ver especificação de criação manual ou por ficheiro UBL.

Ou seja:

5.5 Validações adicionais

É possível o recetor da fatura parametrizar no ilink a obrigatoriedade de certos campos (regras de negócio), mesmo que estes não sejam estritamente obrigatórios na especificação CIUS-PT. Por exemplo, um cliente poderá apenas aceitar faturas que incluem o ficheiro PDF anexado, ou o número de compromisso especificado. É importante que estes dados sejam pré-acordados com o vosso cliente/destinatário antes da passagem a produção para evitar erros de integração.

Caso o recetor do documento obrigue a presença de algum campo não especificado no XML, o API irá retornar um erro como abaixo e o documento não será gerado: 

HTTP status: 400 Bad request
 
{
	success: false,
	errors:{
		commitment_number:{
			code:"e048",
			msg:"O número de compromisso é obrigatório."
		}
	}
}

5.6 Criar/editar documento

Um documento pode ser editado e reenviado ao destinatário

Em termos práticos, a possibilidade de reenvio pode ser consultada através do campo de resposta do documento: 

state_edi_document:{
	alias: <estado> // estados possíveis de reenvio: 'regularization' ou 'reception' ou 'error'
}

Para consultar o estado de um documento, ver secção de consulta de estado de documentos emitidos.

Para editar um documento existente, basta repetir o pedido POST /apps/documentsUBL ou POST /apps/documents com os dados corrigidos, mantendo o número, tipo e data de emissão do documento anterior: 

HTTP status: 200 OK
 
{
	success: true,
	message:{
		code:"s012",
		msg:"Documento editado com sucesso"
	},
	response:{
		data:{
			id:"60796c3c2a6fa2.53909016",
			number:"7411111",
			emission_date:"2021-04-16",
			type_document_fact:{
				id:"5c9cb870a5ef57.36583702",
				code:"380",
				alias:"invoice",
				type:"FT",
				description:"Fatura"
			},
			type_document:{
				alias:"issued",
				description:"Emitido"
			},
			state_document:{
				id:"5c9cb870f34b16.42025494",
				alias:"tosend",
				description:"Por enviar ao cliente."
			}
		}
	}
}

Caso o documento não seja elegível para edição (i.e já foi enviado ou foi aceite pelo cliente final), será apresentado um erro: 

HTTP status: 400 Bad request
 
{
	success: false,
	errors:{
		number:{
			code:"e200",
			msg:"Documento já existe."
		}
	}
}

5.7 Acesso a documentos emitidos

Quando um documento é registado com sucesso, será sempre devolvido um ID nas respostas, que identifica o mesmo perante o ilink. Poderá ser útil guardar este identificador para consultas futuras ao documento. 

HTTP status: 201 Created
 
{
	success: true,
	message:{
		code:"s011",
		msg:"Documento criado com sucesso"
	},
	response:{
		data:{
			id:"60796c3c2a6fa2.53909016",
		}
	}
}

O API permite também aceder a todos os dados (inclusive ao XML e PDF) de todos os documentos previamente emitidos. Para tal, deverão usar o método GET /apps/documents/{id}. O ID recebido na criação do documento deve ser usado como parâmetro aqui para aceder ao documento em questão.

Todos os dados retornados por este método estão disponíveis na especificação acima.

Nota: Caso a entidade emissora do documento tenha configurado a assinatura automática de documentos no ilink, os URLs públicos de acesso ao XML e ao PDF já retornam os ficheiros assinados.

5.8 Consulta de documentos emitidos no portal (opcional)

Os documentos podem também ser consultados no portal de testes do ilink usando as credenciais das entidades que vos foram enviadas. Aqui podem validar visualmente se a informação apresentada está coerente com os dados enviados via API:

img info

Para aceder aos anexos de um documento, deverão aceder ao documento da tabela acima, e aceder ao ícone da lupa:

img info

Nota: Os documentos deverão estar presentes tanto na entidade emissora (seção de documentos emitidos), bem como na entidade recetora (seção de documentos recebidos).

5.9 Consulta de estado de documentos emitidos

É também possível aceder ao estado atual dos documentos previamente emitidos. Esta operação permite ao emissor do documento consultar se o documento foi aceite pelo cliente, ou se está pendente de reenvio/regularização, bem como os motivos que levaram a tal.

5.9.1 Consulta de estado de documento enviado via EDI

O ilink contempla 4 estados possíveis de documento:

Nota: O ilink devolve também o estado de processamento EDI atual do documento (state_edi_document), que é independente dos estados acima. Para mais informação, consultar o Guia de Transmissão de Documentos FE-AP, página 7. Contudo, a leitura do estado EDI nem sempre é relevante para os softwares de faturação.

Existem 3 abordagens para aceder ao estado de um documento previamente emitido: Consulta individual, Webhook de mudança de estado e Reporte de estados.

5.9.2 Consulta de estado de documento enviado via e-mail

No envio de documento via e-mail, é possível consultar o registo de envio e de leitura dos e-mails enviados ao cliente. Note-se que o estado do documento retornado (state_document) não é aplicável neste cenário, pois o documento por norma não é enviado via EDI, e como tal, o seu estado de envio será habitualmente to_send. Este estado deve ser ignorado.

Existem 2 abordagens para aceder ao registo de e-mails enviados de um documento: Consulta individual e Consulta de histórico de documento. 

HTTP status: 200 OK
 
{
	success: true,
	response:{
		data:{
			id:"60796c3c2a6fa2.53909016",
			...
			emails: [{
				id: "634672bab0f3b8.40302642", 
				b_open: true, // true caso o email tenha sido lido pelo recetor
				b_sent: true, // true caso o email tenha sido enviado com sucesso
				created_at: "2022-10-12 08:54:34", // data e hora de envio do email
				opened_at: "2022-10-12 09:14:16", // data e hora de leitura do email
				address: {
				    emails: ["joao.freitas@email.com"] // endereço de envio
				}
			}]
		}
	}
}

Nota: Certos clientes de e-mail (Outlook, etc.) podem bloquear o registo de leitura dos e-mails ao ilink, ficando o b_open a false mesmo que o e-mail tenha sido aberto em algumas situações.

5.10 Consulta de histórico de documentos emitidos

Em modo complementar, é também possível consultar o histórico processual de um determinado documento. Este histórico irá listar todas as alterações de estado que ocorreram no documento por ordem cronológica, bem como os registos dos envios de e-mail para o destinatário, o que permite um rastreio completo de auditoria. Pode ser acedido através de GET /apps/documents/{id}/history.

6. Receção de documentos

6.1 Âmbito

Permite dar entrada aos documentos de faturação no ERP do recetor da fatura, permitindo a sua integração automática nos sistemas contabilísticos. Também permite a comunicação de estados de aceitação dos documentos ao emissor dos mesmos (pago, aceite, recusado, etc.).

Neste fluxo de integração, recomendamos que sejam implementados os seguintes aspetos:

6.2 Métodos de receção

Permite consultar e integrar documentos no sistema em questão. A receção de documentos pode ser efetuada por 2 métodos: Consulta manual de documentos ou Webhook de receção.

Neste modo, é necessário aceder ao endpoint GET /apps/documents. É possível especificar diversos parâmetros de pesquisa de modo a filtrar os resultados obtidos. A resposta deste método inclui os dados principais dos documentos, e adicionalmente a paginação através das propriedades rows (número de elementos por página) e page (número da página a consultar). Consulte a especificação acima para mais detalhes.

Para consultar os detalhes de um documento, bem como os links para os ficheiros XML e PDF do mesmo, deverá ser utilizado o método GET /apps/documents/{id}, usando um dos IDs retornados na lista de documentos anterior.

O endpoint de consulta pode ser acedido periodicamente (num processo em segundo plano), ou mediante a consulta de um utilizador no sistema (em tempo real).

Nota: Aqui, a chave pública é usada no contexto da entidade recetora dos documentos, ou seja, deverão utilizar a chave pública que identifica a entidade que consulta os documentos recebidos.

Importante: Recomendamos uma utilização responsável deste endpoint. Chamadas excessivas a este recurso são de evitar, e poderão levar a 'time-outs' e restrições de acesso.

Neste modo, o ilink toma a iniciativa de comunicar ao ERP quando chega um novo documento ao cliente, dispensando de consultas frequentes ao endpoint GET /apps/documents. Para mais informação, consultar a secção Webhooks.

Nota: Segundo especificação, serão retornados os dados dos documentos num formato estruturado, bem como os URLs públicos para o acesso aos ficheiros XML e PDF do documento.

6.3 Importação e aceitação

Após consultar o documento pretendido, é recomendado que o ERP comunique ao ilink o estado de processamento do mesmo, ou seja, se este integrou corretamete no sistema ou se é necessário retificar/regularizar o documento. Para tal, são necessários 2 passos:

Nota: Não é necessário importar um documento rejeitado.

A correta comunicação de documentos aceites e/ou importados cria um histórico de auditoria e facilita o consumo do API, dado que, caso estejam a adotar a receção de documentos pelo método de consulta manual, quaisquer documentos que tenham sido importados ou rejeitados não são devolvidos novamente. Ou seja, as chamadas a GET /apps/documents não devolvem documentos previamente rejeitados ou importados.

A imagem abaixo demonstra como todas as operações realizadas pelo ERP são registadas no portal do ilink:

img info

6.4 Estados de Processo

Nota: Esta funcionalidade é opcional e não afecta o funcionamento do fluxo de receção de documentos.

O ilink também permite a criação de estados de documento personalizáveis para os documentos recebidos. Caso esta funcionalidade esteja em uso pela entidade atual, será possível listar e alterar este estado de um documento via API. Isto permite a um software externo (como gestão documental) alterar o estado processual do documento no ilink de forma integrada. Todas as alterações de estado de processo ficam registadas no histórico do documento.

O estado do processo é independente do estado normal de um documento (recebido, aceite, etc.). É usado apenas para fins de organização e registo de operações.

Para consultar todos os estados de processo disponíveis na entidade em questão, deverá ser usado o método GET /apps/processstates, que retorna a lista completa de estados, juntamente com o seu identification_code. Para alterar o estado de processo de um documento, deverá ser usado o método PUT /apps/documents/{id}/processstates, usando o campo identification_code para atribuir o novo estado.

Para definir estados de processo para uma entidade, consulte o manual.

7. Casos de uso

A seguinte secção exemplifica algumas situações comuns na criação de documentos CIUS-PT.

7.1 Criação de documentos por envio de dados

7.2 Criação de documentos por envio do CIUS-PT

8. Fluxos API

A imagem abaixo consolida os fluxos de integração do API do ilink acima descritos:

img info

9. Checklist pré-produção

Antes de passar a integração a produtivo, devem validar os seguintes pontos:

Acordo de interoperabilidade (obrigatório)

Envio de documentos (no caso da implementação do fluxo de envio)

Receção de documentos (no caso da implementação do fluxo de receção)

Passagem a produção (obrigatório)

  1. Configurar o URL de produção
  2. Solicitar o token de aplicação e chave(s) da(s) entidade(s) do ambiente de produção à equipa do ilink
  3. Assegurar-se que são efetuadas as autenticações necessárias em ambiente produtivo
  4. Assegurar-se que o cliente tem todas as ligações configuradas no portal do ilink, bem como as transações necessárias (solicitar ao serviço de apoio)
  5. Opcional: assegurar que o cliente tem a assinatura digital configurada no ambiente produtivo.
  6. Opcional: assegurar que o cliente tem o template de envio de e-mail de faturação configurado no ambiente produtivo.