Locations - how documents are received and sent
Overview
The most basic functionality in Link is that it can receive, transform and send documents/data.
In Link, there is a very big conceptual difference between receiving and sending documents which will be covered in their respective chapters.
Note It is simple (for developers) to create new transport types, so don’t panic if you have a special scenario that is not covered by this chapter. To learn about creating custom transport types, read the Link technical guide.
![](../__attachments/2560098346/image-20230627-132242.png?inst-v=a204603b-72d2-4d67-b324-401abe447902)
Receiving documents
In Link, you can receive documents in several ways. As seen in the figure above, there are different types of receive sites as well as the possibility to set up what are called “Polling” locations in Link. These will be explained in detail in the sections below.
Resolving document type, sender and receiver
It is important to understand that in order to process a document correctly, Link needs to know the document type, who sent the document and who should receive it - i.e. who the sending partner is and who the receiving partner is.
In many cases, Link will be able to “learn” these three things just by analyzing the document content because Link has built-in functionality for understanding global standards like EDIFACT, X12 and PEPPOL. This is also easily done using custom formats like CSV or a home-made XML format. In any case, your developers just need to set up the relevant document types and format/variant/versions beforehand.
You can also configure one or several of these pieces of information directly on a Polling location by setting up an Init configuration.
No matter how the document type, sender and receiver are resolved, Link will be able to route the document through the appropriate distribution (assuming a matching distribution has been set up).
Receive sites
The most commonly used receive site is the REST (API). This offers several methods including a way to send documents into Link. Link also offers a more old-school SOAP API.
Depending on individual customer setups, AS2 and/or AS4 receive sites will be available. If you want this option to be available to you, contact your administrator to request the relevant URL, certificates, etc.
Inbound polling locations
Inbound polling locations are often associated directly with a specific partner and you can set up as many as you want. This is explained in detail in the Incoming transport location details chapter.
You can also set up global locations, which is relevant if you receive many mixed documents from a VANS-partner.
Integrated FTP
With Link, you can also integrate your preferred internal FTP software (Cerberus is supported). This makes it possible to add new partner-specific in- and out- folders with just a few clicks in your partner configuration.
Sending documents
Synchronous transport locations
One of the many configuration possibilities for a specific partner is that you can set up one or several outbound locations. A common example would be a designated FTP-folder for delivering invoices, but Link supports many other protocols. You can read about them all in detail here: Outgoing locations.
It’s important to understand that the target outbound location for a specific document flow is configured as a part of the distribution setup.
Asynchronous transport locations
Outbox
Sometimes, companies need Link just to place outgoing documents in a queue from where they can be picked up (e.g. via the Link API) later. The “Outbox” is a queue, and can be chosen as the target location instead of a “real” one.
Testbox
A lot of the work done when establishing new integrations is in testing. Setting the outbound location to “Testbox” on a distribution setup will prevent Link from actually sending a document (which you often do not want to do in test scenarios).