Summary and recommendation
The Payhawk public API is scoped to expense, transaction, and accounting data - not user or employee lifecycle management. Authentication uses a Bearer token (API key) generated by an account owner or admin under Settings > Integrations > API; keys are account-scoped, not user-scoped. No official SDK is published; all integrations are raw HTTP.
Rate limits are not publicly documented and must be confirmed with Payhawk support. For teams building an identity graph across SaaS tools, Payhawk represents a gap: there are no REST endpoints for creating, updating, listing, or deactivating users, and no webhooks for user-management events.
API quick reference
| Has user API | No |
| Auth method | API Key (Bearer token) |
| Base URL | Official docs |
| SCIM available | No |
| SCIM plan required | Enterprise |
Authentication
Auth method: API Key (Bearer token)
Setup steps
- Log in to the Payhawk dashboard as an account owner or admin.
- Navigate to Settings > Integrations > API.
- Generate an API key; copy and store it securely.
- Pass the key as a Bearer token in the Authorization header: 'Authorization: Bearer
'.
User object / data model
User object field mapping is not yet verified for this app.
Core endpoints
Endpoint coverage is not yet verified for this app.
Rate limits, pagination, and events
Rate limits: No publicly documented rate limit tiers found in official sources.
Rate-limit headers: Unknown
Retry-After header: Unknown
Rate-limit notes: Rate limit details are not published in official documentation. Contact Payhawk support for enterprise-level limits.
Pagination method: none
Default page size: Not documented
Max page size: Not documented
Pagination pointer: Not documented
Webhooks available: No
Webhook notes: No webhook support for user-management events is documented in official Payhawk sources.
Alternative event strategy: Poll expense/transaction endpoints for activity data; use SAML SSO for identity lifecycle events at the IdP layer.
SCIM API status
- SCIM available: No
- SCIM version: Not documented
- Plan required: Enterprise
- Endpoint: Not documented
Limitations:
- No SCIM provisioning is documented in official Payhawk help center or developer portal as of research date.
- User provisioning must be performed manually via the Payhawk dashboard or through SAML SSO (JIT provisioning where supported).
- Enterprise plan is required for SSO; SCIM availability is unconfirmed even at that tier.
Common scenarios
The only well-documented API use case is retrieving expense data: GET https://api.payhawk.com/api/v2/expenses with an Authorization: Bearer header returns expense records for downstream processing.
User offboarding has no API path - deactivation must be performed manually in the dashboard, or blocked at the IdP layer via SAML session revocation, which does not deprovision the Payhawk account.
SSO setup (Okta or Entra ID) requires SAML metadata exchange configured in Settings > Security > SSO; users must still be pre-created in Payhawk before or at first SSO login, and JIT provisioning support is unconfirmed in official documentation.
Offboard an employee
- No API endpoint exists to deactivate or delete a user programmatically.
- Admin must log in to the Payhawk dashboard and manually deactivate the employee under People > Employees.
- If SAML SSO is configured, revoking the user's IdP session will block future logins but does not deprovision the Payhawk account automatically.
Watch out for: Without SCIM, offboarding is entirely manual or dependent on IdP session revocation; there is no automated deprovisioning path.
Retrieve expense data via API
- Generate an API key in Payhawk dashboard under Settings > Integrations > API.
- Send GET request to https://api.payhawk.com/api/v2/expenses with 'Authorization: Bearer
' header. - Parse returned expense records for downstream processing.
Watch out for: This is the primary documented use case for the Payhawk API; user-management operations are not supported via this API.
Enable SSO for user authentication
- Navigate to Payhawk Settings > Security > SSO.
- Select your IdP (Okta or Microsoft Entra ID).
- Configure SAML metadata exchange between Payhawk and the IdP.
- Assign the Payhawk SAML app to users in the IdP.
- Users authenticate via IdP; accounts must still be pre-created in Payhawk manually unless JIT is supported.
Watch out for: SAML SSO does not replace user provisioning; employees must exist in Payhawk before or at first SSO login. JIT provisioning support is not confirmed in official docs.
Why building this yourself is a trap
The core integration trap with Payhawk is assuming that SAML SSO covers the full identity lifecycle - it does not. SSO handles authentication; it does not create, update, or remove Payhawk employee records.
SCIM is undocumented and unconfirmed even at the Enterprise tier, meaning any identity graph that depends on automated provisioning state from Payhawk will have a blind spot. There are no webhook events for user lifecycle changes, no pagination details published for list endpoints, and no user-object schema documented in the developer portal.
Until Payhawk ships a user management API or confirms SCIM support, programmatic identity lifecycle management is not a viable path.
Automate Payhawk workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
