Using PeopleForce data in user-facing solutions

Many customers surface PeopleForce data inside user-facing solutions — for example:

• Showing a list of employees
• Retrieving leave requests
• Showing directory data such as positions or departments
• Displaying vacancies on a website

When you build this, implement it carefully to avoid exposing employee data and creating a security risk.

Showing vacancies

For displaying vacancies on a public site, use the dedicated Career API key and the Careers API — see Own career site integration. The Career key is limited to non-sensitive vacancy data, so it's safe in a browser.

Everything else: never expose the API key

For all other data, never put a Service account API key in the browser (frontend). Protect it behind a backend proxy service. This matters even for internal, non-public solutions — a key exposed to your own team is still a data-security risk.

A good pattern is a two-tier architecture: the frontend talks only to your backend, and your backend holds the API key and calls PeopleForce.

1. The user-facing app requests data from your backend — it never references a PeopleForce API key.
2. The backend receives the request and calls PeopleForce, using the API key it holds server-side (optionally filtering by use case).
3. PeopleForce responds to the backend.
4. The backend reduces the response to only the fields the frontend needs, then returns it.

This keeps the API key encapsulated in the backend, where it's never exposed to the client.