Efka Api Integration
ReviewAudited by ClawScan on May 1, 2026.
Overview
This appears to be a purpose-aligned EFKA payroll integration, but it handles government credentials, sensitive employee payroll records, and filing workflows that should be carefully reviewed before use.
Before installing, confirm that only trusted operators can access the EFKA credentials and /data/efka/ directory. Keep the stated four-eyes approval workflow for submissions, review generated APD and employee-change files before upload, and configure Slack or Google Calendar only if those destinations are appropriate for payroll compliance information.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If the credentials are misused or exposed, EFKA declarations or employee records could be affected.
The skill requires EFKA username and password credentials for government submission workflows. This is expected for the stated integration, but it gives the agent access to a sensitive government account.
env: ["OPENCLAW_DATA_DIR", "EFKA_USERNAME", "EFKA_PASSWORD"] ... "EFKA credentials are required only for submitting social security declarations."
Use a dedicated EFKA account if possible, protect the environment variables, and keep human approval mandatory for any submission or account-changing action.
Incorrect inputs or unintended invocation could prepare wrong filings, update payroll records incorrectly, or queue actions affecting many employees.
The documented workflows include bulk payroll processing, employee lifecycle actions, and automatic file processing. These are coherent with the EFKA/payroll purpose, but they are high-impact operations.
openclaw efka monthly-process --payroll-period 2026-02 --all-employees --submit-ready ... openclaw efka employee-terminate ... openclaw efka monitor-files --watch-payroll-updates --auto-process
Run these workflows only on scoped client directories, validate generated files, and require explicit approval before any EFKA portal submission or irreversible employee-record change.
Sensitive employee identifiers, salaries, payroll history, and submission records could be exposed, retained too long, or reused incorrectly if the data directory is not protected.
The file architecture stores employee records, terminated employee records, payroll outputs, and EFKA submission artifacts persistently under /data/efka/.
- /data/efka/employees/active/ ... - /data/efka/employees/terminated/ ... - /data/efka/payroll/processed/ ... - /data/efka/submissions/efka-portal/
Store /data/efka/ in an access-controlled location, apply retention policies, back up carefully, and validate stored records before reusing them for new filings.
Submission status or deadline information could be visible in Slack or Google Calendar to people outside the payroll/EFKA workflow.
The skill optionally integrates with Slack webhooks and Google Calendar for notifications and deadline synchronization. This is disclosed and purpose-aligned, but it may send compliance-related metadata to external services.
"SLACK_WEBHOOK_URL": "Notifications for EFKA submission status updates", "GOOGLE_CALENDAR_ID": "Google Calendar ID for EFKA deadline sync (optional)"
Use private channels/calendars, avoid including employee PII in notifications, and only configure these optional integrations when needed.
