Skip to main content

​
Retrieve your API keys

Gain access to Prove endpoints using an OAuth 2.0 bearer token. To generate a bearer token for the Sandbox environment, follow these steps:
1

Access your Developer Portal account

Login to the Developer Portal.
2

Navigate to the Prove solution

Navigate to Projects from the side bar. Select your previously created project or create a new one, following the next step.
3

(Optional) Create a project

Create a new project, then select the appropriate solution, give your project a name, and then select Create Project.
4

View Credentials

Navigate to the Credentials tab of your project to access your credentials.
5

Test Your Credentials Using cURL

Use the following example cURL request for the /token endpoint to generate a bearer token. Replace the placeholders with your actual credentials.
If you are testing Prove’s APIs outside of North America, make sure to use the EU token endpoint, https://platform.uat.eu.proveapis.com/token and the credentials listed for the International region.
curl -X POST https://platform.uat.proveapis.com/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET"
Response
{
  "access_token": "eyJ...",
  "refresh_token": "eyJ...",
  "refresh_expires_in": 3600,
  "token_type": "Bearer",
  "expires_in": 3600
}
6

Authenticate a Request

Use the bearer token (access_token) in the Authorization header of your requests, replacing the placeholder with your bearer token:
Example Request
curl -X POST https://platform.uat.proveapis.com/v3/start \
  -H 'Authorization: Bearer YOUR_BEARER_TOKEN' \
  -H 'Content-Type: application/json' \
  -d "phoneNumber=2001001695&flowType=mobile"
Prefer Postman? Check out Prove’s API collection to try out different endpoints with test data.

​
Best practices for managing API keys

Secret API keys are a form of account credentials, like a username and password. If bad actors obtain a secret key, they can use it to harm your business. Prove users own the responsibility of keeping secret API keys safe. Here are some best practices for how to do that.

​
Protect against compromised secret API keys

Take the following actions to protect against compromised secret keys:
  • Use secure key management systems (KMS) to store secret keys: When you create a live production secret key, immediately copy the key to a KMS, which handles sensitive information with encryption and access controls. Make sure you don’t leave a copy of the key in a local file.
  • Grant access only to those who need it: Define a clear policy about which users have permission to create, update, or read keys. Limit the access only to those who need it. Audit the access periodically to avoid excess privilege on keys.
  • Don’t share secret keys insecurely: Don’t share keys in emails, chat messages, or customer support messages.
  • Don’t store keys in source code repositories, such as GitHub: Fraudulent actors might scan public source repositories for API keys. Even if the source repository is private, team members might share it from their development environments.
  • Don’t embed secret keys in applications: Fraudulent actors can exploit secret keys by matching a certain string pattern. Avoid embedding keys in applications such as client tools, SDKs, and mobile apps. Mobile apps (APKs/IPAs) and frontend JavaScript can be reverse-engineered. Any key embedded in the client-side code is essentially public.
  • Audit API request logs to check suspicious activities: We recommend that you audit or check API request logs to proactively identify misused API keys. Make sure your developers aren’t using Production keys when a Sandbox key is appropriate.
  • Regular training and updating documentation. Keep up-to-date documentation about how to handle secret API keys within your organization and host regular training sessions to ensure your team follows best practices.
  • Implement a key rotation policy. Periodically generating new keys and decommissioning old ones limits the window of opportunity for an attacker if a key was unknowingly leaked