Ideagen Q-Pulse

Built, not certified Built and tested against recorded and synthetic responses (version 1.0.0, 10 November 2026). Not yet run against the vendor's sandbox or a client environment.

Reads occurrences, with their data fields, from your Q-Pulse through its web services, read-only, inside your deployment, with reporters left out.

At a glance

Collector	Ideagen Q-Pulse, version 1.0.0
Reads	Ideagen: Q-Pulse web services (SOAP) (the vendor's documentation)
Family	Aviation
Kind	Quality
Ways to connect	Access token
Scopes	Read:
Read only	Yes, except: [object Object]; [object Object]; [object Object]
Vendor's API can move money	No
Personal data	Identity, Contact
Hosts it may contact	Only the hosts on your deployment's allow-list (*: the host is the one you give it)
Vendor API versions	Q-Pulse Web Service APIs, API 2.100.7800.0 (namespace v1.2)
Lowest engine version	0.46.0

What it reads

• Occurrences reported in the last days_back days (1 to 3650, default 30; first_days_back, default 365, on the first run), listed by GetOccurrenceIDs with ReportedOnOrAfter and read one by one with GetOccurrence.
• One record per occurrence: its number, title, report type, reported date and data fields.
• Only those three operations are sent (Authenticate, GetOccurrenceIDs, GetOccurrence). The service also creates and accepts occurrences; no envelope for either exists here.

How to connect

1. Create a dedicated integration user in Q-Pulse with read access to occurrences, and note the database name.
2. In LightHouse, open Setup and admin, Connectors, choose Ideagen Q-Pulse, and leave the access level at Read.
3. Name base_url (the https service path of your Q-Pulse web services) and database. To leave a data field that names a person out, list its name in exclude_data_fields.
4. Paste the integration user and then its password. Your browser seals them to your deployment, which hands them to the collector as QPULSE_USER and QPULSE_PASSWORD. Q-Pulse signs in by a SOAP envelope, so your deployment checks the sign-in at the first sync.

Permissions

• The integration user’s own rights in Q-Pulse are the permission. Give it read access to occurrences only.
• Every request is a SOAP POST to one of the three read operations in the manifest’s read_operations. https is required, because the user’s password travels in the Authenticate envelope (Ideagen’s examples use plain http).
• Your deployment refuses to store this credential at read and write.

Limits

• Q-Pulse queries occurrences by reported date, not by change: each run re-reads the occurrences reported in the last days_back days; unchanged ones are not rewritten. An occurrence changed after its window closes is caught by a wider window, or one run with days_back raised.
• Requests are paced at 0.5 s (delay_s).
• The service path varies by installation; the manifest’s host is * for that reason.

Data handling

• Records are read and indexed inside your deployment. LightHouse receives ids, hashes and counts, never an occurrence.
• Reporters are protected by default: reporters’ names, who submitted or created a record, and everyone’s email, phone and contact details are left out of every record before it is written, as are travel document numbers and dates of birth. Just culture and data protection both need a reporter kept from anyone who does not need them. Names are matched whatever the case, spacing, _ or -, so reporterName also catches an export’s Reporter Name.
• exclude_fields adds paths (for example **.contact); keep_fields takes a default back by its exact name, and that choice is your record of the decision. Free-text narratives are indexed as written and may still name people: add the fields that hold them to exclude_fields.
• Nothing is cached raw, and a failure names the host and the status, never the URL.
• ReportedByPersonName and RecordedByPersonName are left out by name. A data field is a name and a value in a list, so a path cannot select it: name any that holds a person in exclude_data_fields.

Troubleshooting

What you see	What it means	What to do
credential variable 'QPULSE_USER' is not set	The deployment has not been given the user or password	Connect the credential again
POST host: Authenticate returned a fault	Q-Pulse refused the user, password or database	Check the integration user and the database name
POST host: the response is not XML	The address is not the web services path	Check base_url against Q-Pulse’s service path
POST host: no AuthenticateResult	The response is not a Q-Pulse answer	As above
Q-Pulse returned no token	The sign-in answered without a token	Check the database name and the user’s licence
base_url is the https service path of the Q-Pulse web services	base_url is not https	Use the https address
name the Q-Pulse database	No database was named	Name it
days_back and first_days_back are 1 to 3650	A window is out of range	Correct it

Certification

Each entry is a run by Atlantic Agentic Labs, newest first. Only a run against the vendor’s sandbox or a client environment certifies a collector; a certification lasts six months, or less if the vendor publishes an API version the collector does not list. See How collectors are certified.

Date	Collector	Engine	Vendor API	Method	Expires
10 November 2026	1.0.0	0.47.0	Q-Pulse Web Service APIs, API 2.100.7800.0 (namespace v1.2)	Fixtures only: built, not certified	Not applicable

Security posture

From the collector’s last scan on the default branch. What each line means, and what blocks a release: Security posture.

Last scanned	10 November 2026
Critical findings	0
High findings	0
Medium findings	0
Low findings	0
Info findings	0
Release blocked	No
Network allow-list check	Pass
Read-only behavioural test	Pass
SBOM (CycloneDX)	Produced
Dependency licences	Pass
Scanners	bandit 1.9.4, semgrep 1.181.1, pip-audit 2.10.1, osv-scanner 2.7.0, cyclonedx-py 7.5.0, pip-licenses 5.5.5, gitleaks repository job aal-secrets, hosts_check tools/hosts_check.py, read-only test pytest -m read_only