API v2: key-pair authentication
Your integration authenticates with a key pair. The private key stays with you
and signs every request; we store only the public key. There is no client_secret.
Nothing that leaks on our side lets anyone impersonate you, because there is nothing on our side to leak. A stolen access token is useless on its own: every call must be signed by a key we never hold.
STEP 1
Generate a key pair
EC P-256, in your own infrastructure.
STEP 2
Register the public key
One credential = one key, one account, one profile.
STEP 3
Get a token
Short-lived: 60 seconds, any profile.
STEP 4
Sign every request
DPoP proof per call, bound to method, URL and body.
REFERENCE
Errors
What each rejection means and how to fix it.
MOVING FROM v1
Migration
Side by side with the current integration.
What changes from v1
| v1 | v2 | |
|---|---|---|
| Credential | client_id + client_secret | client_id + your public key |
| Token request | secret in the body | JWT signed by your private key |
| Token lifetime | 2 hours | 60 seconds |
| Stolen token | works until it expires | useless without the private key |
| Per-request proof | none | DPoP proof, bound to method, URL, query and body |
| Revocation | disables the secret | irreversible, and takes effect in about a second |
v1 keeps working. v2 is a separate surface under /v2/*, so you migrate one integration at a time.
The addresses
| Environment | Authentication | API |
|---|---|---|
| Sandbox | https://api.sdb.lbpay.com.br/v2/oauth/token | https://api.sdb.lbpay.com.br/v2/* |
| Production | https://api-secure.lbpay.com.br/v2/oauth/token | https://api-secure.lbpay.com.br/v2/* |
What a request looks like
What you need to build
Two short JWTs, both signed ES256 with your private key: the client assertion and the DPoP proof. Any library that signs a JWT does it, and so does your language's standard library. The examples in this section use no dependency for the signing part.