Auth & access

Authentication

Two mechanisms: OAuth 2.0 for partner applications and bearer API keys for server-to-server calls.

OAuth 2.0#

Used by partners building consumer-facing applications on top of the Pierflow API. Standard client-credentials grant.

token.request

bash

POST /auth/v1/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=pf_live_cid_xxxxx
&client_secret=pf_live_cs_xxxxx
&scope=enrollment plans pricing claims

200 OK

json

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "enrollment plans pricing claims"
}

API keys#

For pure machine-to-machine calls, an API key in the Authorization header is enough.

http

Authorization: Bearer pf_live_sk_xxxxxxxxxxxxxxxxxxxxxxxx

Key format#

pf_test_sk_… / pf_live_sk_…

secret key

Server-side only. Pattern: pf_{environment}_{type}_{random}. sk = secret, pk = public.

pf_test_pk_… / pf_live_pk_…

public key

Safe to embed in front-end builds. Limited to read-only scopes.

pf_test_cid_… / pf_test_cs_…

OAuth credentials

Used with the /auth/v1/token endpoint to exchange for access tokens.

Rotation#

Rotate any credential from the developer portal. New keys activate immediately; old keys remain valid for 24 hours unless explicitly revoked.

If a key is ever exposed

Revoke immediately from the portal. Pierflow will not invalidate the old key without your explicit action — even if traffic patterns look suspicious — so prefer manual revocation over silent rotation.