Peak Payment Solutions — REST API
The Peak API provides programmatic access to Peak Payment Solutions. Each capability is documented as its own OpenAPI reference below. The conventions on this page — authentication, the response envelope, error shape, dates, and pagination — are shared by every endpoint, so read them once and they hold across all of the references. The current version is v1, served under the /api/v1 base path.
Peak's original /api/* surface, documented for existing partner integrations. It predates the v1 conventions above and follows its own, described in the reference. New integrations should use the v1 API.
https://secure.peakpayment.com, with every v1 endpoint under the /api/v1 base path.Authorization: Bearer <token> header. There is no query-parameter API key on v1. Your key works on every v1 endpoint for your authorized clubs — access is not restricted by capability.{club} in a path must be one of them. Call the Locations reference to discover that set. An unauthorized club returns 403 forbidden_club — as does a club code that does not exist, so the surface never confirms which clubs are real. A record that exists in a club you are not authorized for returns 404, not 403: outside your key's reach, a resource reads as absent rather than refused.data, alongside status, request_id, and — on list endpoints — pagination as sibling keys. Every response carries an X-Request-Id header mirroring the body request_id, and a 201 create also returns a Location header.Idempotency-Key header so a retried call is applied at most once.Z suffix and no fractional seconds, e.g. 2026-05-26T14:30:00Z; conversion happens at the API boundary, in each location's own timezone. Calendar-date fields (those with no time component, such as birth_date and join_date) are ISO-8601 YYYY-MM-DD.error object; an errors array appears only for multi-field validation. See the ErrorResponse schema in any reference.total_count.