What is transmitted?
Simplified page, for a publisher to whom Eiger Vault delivers a plugin for its CMS.
You do not have to write any code. Eiger Vault writes a small module, a plugin, that you install in your CMS. It sends our copies of the articles at the moment they are published or modified, with your key. This page says what it does, when, what it sends, and what it never reads.
No plugin has yet been delivered: the list below is the specification that we hold ourselves to, not the description of a product in service. It will also depend on what your CMS allows.
What the plugin does
It hooks into the publication events of your CMS. At each publication, and at each visible modification of an already published article, it builds a document that describes the article, and sends it to Eiger Vault over a secure connection (https, the only address it accepts). It waits for the response, and considers the article delivered only once that response has been received.
When it runs
- At each visible modification: the text, the headline, the standfirst, the authors, the category, the displayed publication and update dates, the images and captions, the canonical address. A silent correction, which does not change what a reader sees but changes the text, is included. It pushes on no other occasion.
- Every hour, to catch up on anything missed: it re-reads the list of articles published or modified in the last 48 hours, asks Eiger Vault which of them it does not know, and sends only those. These values are starting values. If your CMS does not allow such a list to be re-read, an exemption is written in the configuration, with its reason.
- In the event of failure: it sends the same content again, with the same revision, without risk: sending it again never creates a duplicate.
What it sends
For each article, only what the reader sees:
- the text, split into blocks: paragraphs, subheadings, sidebars, captions;
- the headline, the standfirst, the language, the authors, the places, the category, the genres;
- the displayed publication and update dates;
- the canonical address of the article;
- the images, the page as a PDF and the videos, if you decide so, with their captions;
- the article's identifier in your CMS, which serves as the reference, and a revision number that serves to avoid duplicates;
- where applicable, rights (embargo, licences, prices), according to rules that you write in the plugin's configuration; without a rule, it sends none;
- the keywords of your CMS, in a separate part that we accept without using it for the time being.
What it never reads, and never sends
- a draft, or an article that is not published;
- an internal note, the state of an editorial workflow, an editing lock, a position in the layout, a reading counter, a technical modification date;
- nothing that is not in the article itself: neither your users, nor your subscribers, nor your statistics.
Where your key goes
The key that we hand you lives only in the plugin's configuration, that is, in your CMS. It is written in no trace. It travels only in a request header, never in the address. We do not keep it: we keep only a digest and a short prefix to recognise it. You may at any time ask us to revoke it and to issue a new one.
What we check
The plugin's code is reviewed by Eiger Vault before being delivered, and it lives in its own code repository, which consumes only our deposit contract. It keeps no copy of the articles. The only destination it contacts is Eiger Vault's deposit address.
If it goes wrong
If Eiger Vault is unavailable, or refuses a submission, the plugin records it in its own log, without the text of the article, and tries again. Each refusal has a stable code, which you can give us together with the correlation identifier that the response carries.