Reads from the systems you run
Bills in the form they arrive, the monitoring your network team runs, your directory, your SIEM and your own mail. Each connection below says what it reads.
Bills
Every bill, in the form it arrives
Every path goes through the same checks and review as an upload.
| Source | How it reads |
|---|---|
| CSV and XLSX | Through a column mapping a person confirms once and Riopex reuses for that layout, never sent to a model. |
| By the intelligence engine once a group administrator switches it on, from masked text only; every bill it reads waits for a person, and the fields it is least sure of are marked for checking. | |
| Structured e-invoices | UBL 2.1, credit notes included, read at once with no mapping question and no model. |
| Bilingual invoices | Arabic and English layouts, Arabic-Indic digits and the Arabic separators; a Hijri issue date is read, then confirmed by a person. |
| Billing connections | Where a provider offers one, its bills are collected on a schedule. |
| Provider portals | Bills collected on a schedule, so the history is kept after the portal drops it. |
| SFTP drops | Files a provider leaves on an SFTP drop are collected and read like an upload. |
| Your billing mailbox | Bills emailed to the group's billing mailbox are picked up and read like an upload. |
| Typed in by hand | A bill can be typed in by a person instead of uploaded. |
| Exchange rates | Published reference rates collected on a schedule, beside the rates the group enters itself. |
| Settlement statuses | Imported from a file for a chosen company. |
Monitoring
Reads the monitoring you already run
Riopex measures a link three ways: from the device, from your monitoring system, or from the reports you upload.
| System | What it reads |
|---|---|
| The device, over SNMP v3 | Traffic counters, polled directly, only from interfaces bound to a service, by a poller inside your own network that needs no inbound connection. |
| PRTG | Utilisation history through its API, with calls paced so polling never overloads your monitoring server. |
| Zabbix | Utilisation history through its API. |
| SolarWinds | Interface traffic, with SolarWinds' own measure of how much of each hour it measured. |
| LibreNMS | Port traffic. |
| ManageEngine OpManager | Interface utilisation. |
| Cisco Meraki | Each site's uplink usage from the dashboard, hour by hour. |
| Fortinet FortiAnalyzer | Interface bandwidth from its reports; that source alone never justifies a finding. |
| The history you upload | An export from PRTG or Zabbix, joined to a service only when its identifier matches exactly; readings coarser than an hour are refused. |
Every connection
What a connection may change
The list of outside services an instance may reach is kept equal to the hosts the code actually calls.
Read level only
Riopex asks a monitoring system for a read-only key and never writes to a device.
Sealed credentials
A provider credential is stored as a sealed envelope, opened only by the background worker. It can be replaced or deleted, but never read back.
Configured addresses only
A monitoring or SIEM connection reaches only an address a person has configured.
Your mailbox as it is
Riopex never flags, moves or deletes a message in your mailbox.
Identity
Sign-in and people from your directory
Single sign-on and directory provisioning use the group's own address, so moving its instance never touches its identity provider or directory.
| Connection | What it does |
|---|---|
| OIDC and SAML | Single sign-on, Microsoft Entra ID and Okta included. |
| SCIM 2.0 | Your directory adds and removes people, and removing someone withdraws their access in that group at once. |
| Directory groups | A directory group maps to a role, and a mapping never gives more access than its author could give. |
| Directory tokens | Made inside the database, shown once, stored only as a hash, and set to expire. |
| Your provider's second step | Your identity provider's multi-factor sign-in can stand in for Riopex's own second step. |
| Google and Apple accounts | People sign in with one where the group allows it. |
Audit
The audit chain, out to your SIEM
A SIEM connection reaches only an address a person has configured.
| Connection | What it sends |
|---|---|
| The audit API | Your security team pulls the audit chain and its checkpoints with a read token, and every read is itself recorded in the chain. |
| Audit API tokens | Issued from a session that passed two-step sign-in, shown once, and limited to a list of source addresses if you choose. |
| Syslog over TLS | Riopex pushes the audit chain to your SIEM, each entry labelled with its family so the SIEM can filter by it. |
| Signed checkpoints | Delivered to the group, signed with a key the database never holds. |
AI
Your engine, reading your instance
Each is off until a group administrator switches it on.
| Connection | What it reads |
|---|---|
| The Model Context Protocol (MCP) server | Your own AI engine reads your instance through it, as one person and never more than that person could open. |
| MCP sign-in | An MCP client signs in through your instance's own sign-in over OAuth, with no token to paste. |
| MCP client configuration | Riopex supplies a generic one and leaves the choice of engine to you. |
| The intelligence engine | One Riopex runs where your instance runs, one your group provides, or off; a group that allows no outside engine runs one inside its own network. |
Providers
Orders and mail to your providers
Each handoff to a provider is recorded.
| Connection | What it does |
|---|---|
| Ordering handoffs | A request goes to the provider by email, portal, phone or its ordering API on the TM Forum TMF622 standard, and to the API only once approved. |
| Order status | Riopex asks each provider for its open orders' status and opens no inbound callback for a provider to call. |
| The provider's service list | Where a provider offers it, read in through its API as evidence for a person to check, never over the inventory. |
| Your mail system | Riopex sends and reads provider mail through a mailbox in your own mail system, over IMAP and SMTP with TLS. |
| Microsoft 365 and Google Workspace | A mailbox connects by signing in over OAuth, with no password stored. |
Questions
Questions about connections
Does a provider's own service list change our inventory?
No. Where a provider offers it, its list of the group's services is read in through its API as evidence for a person to check, and never overwrites the inventory.
Can FortiAnalyzer figures raise a finding?
Not on their own. Riopex reads interface bandwidth from Fortinet FortiAnalyzer reports, and that source alone never justifies a finding.
How does a Microsoft 365 or Google Workspace mailbox connect?
By signing in over OAuth, with no password stored.
How is coverage counted from SolarWinds?
Riopex uses SolarWinds' own measure of how much of each hour it measured.
Start with the files you hold
Three invoices from one company, as the provider sent them. Your network team joins later to connect monitoring.
Request a pilot