API integration
You can issue a client ID and client secret from the dashboard. The secret is shown only once, at the moment you create it.
Issuing credentials
Use "OAuth client" in the menu.
-
Open the screen
After signing in, choose "OAuth client" from the menu.
-
Generate
A client ID and client secret are displayed.
-
Store the secret somewhere safe
Read the warning below first.
The client secret is shown only once
It cannot be displayed again after you close the screen. Save it into a password manager or secret store immediately.
If you lose it you must regenerate — but regenerating invalidates the previous credentials. Live integrations will stop, so plan the switchover first.
What regenerating does
Regenerating invalidates the previous client and every access token already issued.
| Impact | Detail |
|---|---|
| Existing integrations | Authentication fails and all API calls stop |
| Issued tokens | All revoked |
| Recovery | Configure the new credentials in your systems |
With a live system, avoid regenerating during business hours. Payment and order integrations stop until the new values are in place.
If you suspect the secret has leaked, regenerate immediately and accept the outage.
Handling credentials
| Do | Do not |
|---|---|
| Keep them in environment variables or a secret store | Hard-code them in source |
| Use them only from server-side code | Embed them in a browser or mobile app |
| Limit who has access | Share them over chat or email |
| Regenerate when staff leave | Keep using the same values indefinitely |
Never put a secret in a support ticket
Do not paste client secrets or access tokens into tickets or chat. Our staff will never ask for them.
When contacting us, send the client ID only.
Common errors
| Symptom | Likely cause | What to do |
|---|---|---|
| Authentication fails (401) | Regenerated but old values still in use, or a copy error | Reconfigure with the current credentials |
| Forbidden (403) | That feature is not in your contract | Check with support |
| Rejected (429) | Too many calls in a short window | Add back-off and retry |
| Intermittent failures | Transient network or processing errors | Retry, and make payment calls idempotent |
A failed connection does not always mean the other side failed to process it. Design so that repeating the same operation cannot double-charge — deduplicate on the transaction ID.
Do you actually need the API?
If a payment link covers your use case, you do not need API integration. Payment links need no development and can notify your systems by webhook.
The API is the right choice when you want to:
- Keep balances in sync with your own membership system
- Process large volumes automatically
- Build your own checkout experience
For technical questions, open a support ticket with the API you called, a summary of the request, and the error returned. Again — never include the secret.
Did this page help?
Your answer tells us which pages need rewriting.
- Your business name
- Your client ID (never include the secret)
- Which API you called and the error you received
Never include your password, verification codes or card PIN. How tickets work