secvest-api

Reverse-engineered documentation of the REST API that the official app uses to talk to the ABUS Secvest Touch (FUAA50500) alarm panel. The goal is a complete OpenAPI specification that home-automation integrations can build on.

Only facts about the interface are recorded — no firmware, app binaries or decompiled code are part of this repository.

Tested with a Secvest Touch FUAA50500 running firmware v3.01.31. Other firmware versions are untested; please report differences.

The requests behind the panel's web interface (sec_*.cgi, *.cgx) are a different interface with a form login, session and CSRF token; they are documented separately in openapi-webui.yaml (login, session, overview, Info, the wireless zone list and logout captured).

Disclaimer: This is an unofficial community project, not affiliated with or endorsed by ABUS. The panel is security equipment — use this at your own risk, never load-test it, and be careful with anything that arms, disarms or switches outputs.

Don't expose the API to the internet unprotected. As far as tested, failed logins at the REST API neither raise the code tamper alarm nor leave a log entry, and nothing limits them (see Unauthorized in the specification). Credentials can therefore be guessed without anyone noticing, and the load alone may make the panel hang. Keep it in the local network, or put a reverse proxy in front that restricts access and limits failed logins; a User-Agent check is no protection, since any client can send the app's User-Agent.

Layout

Path	Content
openapi.yaml	The specification; grows with every finding
openapi-webui.yaml	The web interface's requests (login, session, overview, logout, component lists); its fixtures are the *.cgx.xml files in fixtures/
fixtures/	Redacted example responses, named after method and path (GET_system_partitions-1_zones.json); further examples of the same request get .example2, .example3, …; request bodies end in .request.json, error responses carry the status code (GET_system.403.json)
docs/app-behavior.md	How the official app uses the API (screens, polling, timing)
docs/panel-behavior.md	Background from the ABUS manuals: zone types, arming, alarms, reset
docs/firmware-reverse-engineering.md	Firmware analysis: method, results and limits
scripts/redact.py	Redacts raw captures and checks fixtures before a commit
captures/	Raw captures, not versioned

Evidence levels

Every operation carries x-evidence, and x-sources where it comes from third-party code:

• verified — observed on a real panel, the redacted response is in fixtures/
• source — taken from third-party code or reports, docs, the panel firmware's strings or a static analysis of the official Android app (x-sources says which) (node-red-contrib-secvest, homebridge-secvest, PySecvest, for the web interface secvest-ha), not checked yet
• assumption — educated guess

What is still unknown is listed in x-open-questions, on the operation it belongs to or at the top of the spec.

Redaction

Nothing that identifies an installation goes into git: host names, IP and MAC addresses, serial numbers, user codes, phone numbers, SIP accounts, zone or user names.

1. Copy redact.example.json to redact.local.json (gitignored) and list the installation-specific strings with neutral placeholders. Keep the mapping fixed (e.g. always the same room number for the same room), so fixtures stay comparable.
2. Keep raw responses in captures/, then redact them into fixtures/:

   scripts/redact.py captures/GET_system_partitions.json fixtures/GET_system_partitions.json

3. Before every commit:

   scripts/redact.py --check fixtures openapi.yaml openapi-webui.yaml

Built-in rules replace IPv4, MAC and e-mail addresses and blank out values of sensitive-looking JSON keys (serial, code, pin, username, phone, sip, …). Always review a fixture by eye as well — the rules can't know every field.

License

MIT