Skip to main content
The Partner API uses the OAuth 2.0 client credentials grant with private key JWT client authentication (RFC 7523, updated by RFC 10070). Your backend signs a short JWT, the client assertion, with its private key. Gnosis Pay verifies the signature with the public key that you registered and returns an access token.
Run this flow only on a trusted backend. Never put your private key, client assertions, or access tokens in a browser or mobile app.

Create a key pair

This guide uses an Ed25519 key, which signs with the EdDSA algorithm. The token_endpoint_auth_signing_alg_values_supported field of the server metadata lists all the algorithms that the server accepts. Use OpenSSL 3.0 or later, and run the commands on your own machine. Never use a web tool to create a private key.
On macOS, the openssl command is LibreSSL. Older LibreSSL versions cannot create Ed25519 keys and show the error Algorithm ED25519 not found. Install OpenSSL 3 with Homebrew and put it first in your PATH:
1

Create the private key

The command writes a PEM file in the PKCS#8 format:
2

Derive the public key

3

Verify the key pair

Make sure that the public key comes from the private key. The two fingerprints must be equal:
Never share private.pem. Anyone who has it can get tokens in the name of your organization. Store it in a secret manager.

Register your public key

Send public.pem to Gnosis Pay. Never send the private key. If you send a private key by mistake, create a new key pair. Gnosis Pay registers the key and supplies these values for each environment. Store them as configuration, not in code. The kid is the RFC 7638 JWK thumbprint of the public key, with SHA-256 and base64url without padding. Your backend can also compute it from the key. The Go sample shows how.
You can have at most 5 active keys. To rotate a key, register the new key, move your backend to it, and then ask Gnosis Pay to revoke the old key.

Get and use a token

1

Read the server metadata

The server metadata (RFC 8414) gives the issuer, the token_endpoint, and the accepted signing algorithms:
cURL
The token endpoint is POST <issuer>/oauth/token.
2

Sign a client assertion

Create a compact JWS with one signature and these headers and claims:The server accepts a clock skew of 30 seconds. Sign a new assertion for each token request. Do not reuse an assertion.
3

Request an access token

Send the client assertion to the token endpoint as an application/x-www-form-urlencoded body:
cURL
A success response has status 200:
The access token is valid for 15 minutes.
4

Cache the token

Use the same access token for all API calls until its refresh time. Then request a new token. Don’t request a new token for every API call.
Set the refresh time to 1 minute before the token expires: the time of the token response, plus expires_in, minus 60 seconds. This margin covers a difference between your clock and the server clock, and a slow network. It also keeps your backend below the limit of 60 accepted token requests per minute.
5

Send the token with every request

Pass the token as a bearer token in the Authorization header:
cURL
A token is scoped to one partner organization, so you don’t send an organization ID in Partner API requests. The token gives access to every resource in your organization. Check that a resource belongs to the requesting user before you act on it.

Token request reference

Parameters

Send each parameter one time only. The server reads the parameters only from the body, not from the query string.

Errors

An error response follows RFC 6749 §5.2:

Rate limits

Go sample

The sample uses github.com/lestrrat-go/jwx/v4 and needs Go 1.27 or later. It does these steps:
  1. Load the private key from private.pem and compute its kid.
  2. Sign the client assertion.
  3. Exchange the client assertion for an access token.
  4. Print the access token on stdout.
Replace the issuer and clientID constants with the values from your integration.
main.go

Next step

Configure webhooks

Set up an endpoint to receive state changes from Gnosis Pay.