Payroll & HR
Multi-Org Payroll APIs Scoped to One Customer at a Time
A single KeyPay API key sees every customer's payroll data. RequestRocket locks each integration partner to one organisation, strips banking and PII fields from reporting responses, and logs every request — so developers never have broader access than they need.
The Challenge
One API Key, Every Customer's Payroll Data
The KeyPay (Employment Hero) Payroll API uses HTTP Basic Auth with a single API key as the username. That API key grants access to every organisation (business) the account manages — dozens of customers for an outsource payroll provider. The only mechanism to scope access to a single customer is the business ID embedded in the URL path: /api/v2/business/{businessId}/... Anyone with the API key can change that path segment and access any customer's employees, pay runs, leave, bank accounts, and tax file numbers. When integration partners needed to build reporting pipelines pulling payroll data into Power BI, Tableau, or other BI tools, the payroll provider faced a decision: share the master API key (granting access to all organisations) or build a bespoke middleware layer to enforce isolation.
A Single Key Unlocks All Organisations
The KeyPay API key grants access to every business the account manages. There is no built-in mechanism to issue a credential scoped to a single organisation. Every developer, integration, and BI tool that holds the key can enumerate and query all customer data.
Bank Account and TFN Data in Reporting Responses
Report endpoints return full employee detail including BSB/account numbers, tax file numbers, and superannuation fund details. An integration built for headcount or cost reporting has no legitimate reason to receive that data, but the API provides no field-level filtering.
Integration Partners Cannot Be Given the Master Key
Sharing the master API key with an external integration partner — even with contractual controls — creates an unacceptable blast radius. A single compromised integration exposes every customer's payroll.
No Audit Trail on Third-Party API Access
The KeyPay platform logs access internally, but does not expose a per-integration audit trail. The payroll provider cannot answer: which integration partner accessed which endpoint, when, or what data was returned.
The Solution
One Proxy Per Customer: Set the Target, Restrict to Read-Only, Strip the PII
The team created a RequestRocket proxy for each customer organisation. Each proxy's target base URL includes the customer's business ID path prefix (e.g. https://api.yourpayroll.com.au/api/v2/business/12345), so every request through that proxy is directed to that single organisation by default — no path manipulation possible. A simple rule restricts access to GET requests only. Response filters strip bank account numbers, BSB codes, tax file numbers, and superannuation details from every response before it reaches the integration partner. The integration partner authenticates to RequestRocket with their own scoped credential and can only access the single customer organisation assigned to their proxy.
"Our integration partners now build directly against the KeyPay API through RequestRocket. They get exactly the data they need for reporting, and nothing else — no bank details, no other customers, no risk."
How it works
- 1
Create a target in RequestRocket with the base URL set to the customer's organisation path: https://api.yourpayroll.com.au/api/v2/business/12345 (where 12345 is the specific customer's KeyPay business ID). Store the payroll provider's master API key as a target credential with credentialAuthType 'basic', setting username to the API key and password to any value (KeyPay ignores the password field when authenticating via API key). All requests through this target are now scoped to that single organisation — the integration partner cannot change the business ID because it is part of the target URL, not the request path.
- 2
Create a proxy wiring the target and credential together. Add a rule with effect 'allow' and methods ['GET'] to restrict access to read-only operations. Set proxyDefaultRuleEffect to 'deny' so anything other than GET is blocked.
- 3
Add response filters with effect 'destroy' targeting JSON paths that contain banking and PII data — fields like bankAccountBsb, bankAccountNumber, taxFileNumber, superFundMemberNumber, and any nested bank account objects. These fields are removed from every response before it reaches the caller.
- 4
Create a Basic Auth proxy credential for the integration partner. This is what their BI tool authenticates with. The credential is bound to the customer-specific proxy — it cannot reach any other proxy or organisation.
- 5
The integration partner connects their BI tool (Power BI, Tableau, etc.) using the RequestRocket proxy URL and their proxy credential. They query KeyPay reporting endpoints directly through the proxy — e.g. /report/paymenthistory or /employee — and the target base URL prefixes the customer's business path automatically. The response filters ensure they never receive banking or PII data.
The Results
Measurable Impact
Each integration scoped to a single organisation
The target base URL includes the customer's business ID, so every request is directed to that organisation by default. An integration partner cannot enumerate other organisations or access another customer's data — the business ID is not in the request path they control.
Banking and PII redacted from all reporting responses
Response filters remove BSB, account numbers, TFN, and superannuation fields before the response payload leaves RequestRocket. The integration partner's BI tool receives payroll cost, headcount, and leave data — nothing more.
Master API key never shared with integration partners
The KeyPay API key remains vaulted in RequestRocket. Integration partners authenticate with their own RequestRocket credential and never see, hold, or transmit the upstream key. Revoking a partner requires one credential deletion.
Full audit trail per integration partner
Every request is recorded with the integration partner's credential identity, the customer organisation path, HTTP method, status, and timestamp. The payroll provider can answer exactly who accessed what, when.
FAQ
Frequently Asked Questions
Add outbound API security
without changing code
Start on your own or talk to our team about improving the security of every API call you make.