Articles Web Interface

The Web Interface lets anyone request a report from a phone or any other device, without opening Articles itself. They tap a link, land on a simple web page, tap a button, and the report is generated and emailed to the address already configured on that report. No login is required.

How It Works

The flow has three steps:

  1. A link to the web page is shared once (by email, bookmark, intranet page, however it gets there).
  2. Opening that link shows a page with buttons. Each button represents one report.
  3. Tapping a button asks Articles to generate that report and email it. The browser never sees the report's file path or its parameters — only a name. Articles looks up everything else on the server side.

Once requested, the report joins the same job queue used by the webhook API below, and is processed by the background poller the next time it runs.

Enabling the Web Interface

The web interface runs on the same listener as the webhook server, on one port. It is configured with four settings:

  • Port — the port the server listens on (e.g. 8765).
  • Secret — used only by the webhook API (see below). Leave blank to disable webhook authentication.
  • Web Folder — a folder on disk containing the web pages (and any images/css) that should be reachable from a browser.
  • Report Buttons File — the path to a reports.ini file that defines which report each button name maps to.

Any file placed in the Web Folder becomes reachable at http://yourserver:port/filename.

Adding Report Buttons (reports.ini)

Each report button is one section in the ini file. The section name is what appears in the page's link (?report=SectionName).

[TodaysSales]
Caption=Today's Sales
ReportFileName=C:\ProgramData\Articles\Reports\TodaysSales.fr3

[ARAging]
Caption=AR Aging Summary
ReportFileName=C:\ProgramData\Articles\Reports\AR_Aging.fr3
AsOfDate=2026-06-20

Caption and ReportFileName are required. Any other key in the section is passed to the report as a parameter — in the example above, AsOfDate becomes a report parameter named AsOfDate.

Note: values in this file are static. A date typed here will still be that same date next week. Reports that need "today's date" should calculate it themselves rather than relying on a parameter from this file.

Changes to this file are picked up the next time the Web Interface is reloaded — no need to reinstall or rebuild Articles.

Building the Web Page

A button is just a plain link pointing at the report's name:

<a href="/run?report=TodaysSales">Today's Sales</a>

No special markup is required. Place the finished .html file in the Web Folder and it is immediately reachable.

Serving Images and Other Files

The Web Folder is not limited to HTML. Images, CSS files, and other assets placed there are served automatically with the correct file type, so a page can include a logo or icons:

<img src="/logo.png">

The Webhook API

Separately from the buttons above, Articles also accepts report requests from other programs (automation tools, scheduled tasks, other systems) via a POST request to the same port:

POST http://yourserver:port/
Header: X-Webhook-Secret: your-shared-secret

{
  "ReportFileName": "C:\\ProgramData\\Articles\\Reports\\Label_2x1.fr3",
  "Parameters": {
    "StartDate": "2026-01-01",
    "CompanyName": "Acme Corp"
  }
}

Unlike the buttons on the web page, the caller here supplies the file path and parameters directly, so the secret header is required to use this endpoint. If the secret is blank in settings, this check is skipped.

Clearing the Report Queue

Every report request, from either the web page or the webhook API, is recorded in a queue table so it can be processed in the background. Over time this table can grow. A "Clear Queue" action is available to remove old entries:

  • By default, only completed and failed entries are removed — anything still waiting to be processed is left alone.
  • An option exists to clear everything, including items still waiting.

Clearing also reclaims the disk space the queue file was using, not just the rows in the table.

Security Notes

There is no login on the web page or its buttons. This is intentional: a request only ever results in the report's already-configured recipient receiving an email — it does not display data to whoever clicked the button, and it cannot be redirected to a different address. The realistic risk of an unintended request is an extra, harmless email to a known recipient, not exposure of data.

The page should still be treated as semi-private — share its address only with the people who should be using it, the same as any internal tool.

Traffic to and from the server is not encrypted unless a reverse proxy with HTTPS is placed in front of it. This affects the privacy of what is sent, not the security model above, and can be added later without any change to how Articles itself is configured.