Our playground environment provides a similar experience to our production environment. It supports API access using OAuth 2.0 and OpenID Connect, and also provides a frontend experience. The dataset available in the playground environment is fake data that is comparable to that found in production.

To access Carta's API in the playground, you will use leverage OAuth in same way as in production. Your playground app's client ID and client secret will let you develop and test your integration in the playground environment. Your access to data elements through OAuth will be based on the permissions already held by a specific Carta user login. More information about Carta's OAuth implementation can be found here.

We support two different OAuth grant types depending on your integration type.

OAuth endpoints

You can find the Playground OAuth endpoints in the Developer Portal under the Playground tab. You will need a developer account to access the Portal.

Data access

The playground environment contains dummy data which largely reflects what you will find in production.

When your application requests access to a user or organization's Carta data, you will specify a list of OAuth scopes that give access to one or more of our API resources. After the user or organization grants access, our API returns an access token to your application which you can then use to access our API resources.

🚧

Do not add confidential information to playgrounds

Playgrounds are a shared environment that reset on a daily basis.

You may not add any confidential or personally identifiable information to this environment because it will be visible to our other partners who are also using these playgrounds.

User Personas and permissions

A user must not only allow your application to access our API on their behalf, but they must also have the appropriate permissions to view or modify the data related to your API requests.

Access to Carta data can vary significantly between user permissions. For example, the HR administrator role can access security and stakeholder information related to employees, ex-employees, and consultants, but not other types of stakeholder. In contrast, a different role could provide security and stakeholder information for all stakeholder types.

See our Support article about Permissions and Roles to learn more about how Carta controls data access.

When you interact with the playground environment using the authorization code flow, you will need to select a user persona to simulate. We support a variety of personas so that you can simulate different user types.

📘

Authorization code flow: Playground vs. production

For production, instead of interacting with a dropdown menu like below, the end-user who is authorizing your access will login to Carta with their email and password, and confirm that they agree to grant your application access to their data.

The below table outlines which playground personas are best suited to each API category.

Rate limits

We rate-limit access to our API to maintain our platform's stability. We include information about your usage in each response to help you monitor your usage and avoid "Too Many Requests" errors.

These are the current limits in place at the OAuth application level for the playground environment:

• Up to 5 requests/second
• Up to 150 requests/minute

📘

Note

Partners can burst to 5 requests/second per OAuth app, but are limited to 150 requests/minute.

See our production rate limits.

Response headers

We return the following headers in every API response:

RateLimit-Limit: 5
RateLimit-Remaining: 4
RateLimit-Reset: 1
X-RateLimit-Limit-Second: 5
X-RateLimit-Remaining-Second: 4
X-RateLimit-Limit-Minute: 150
X-RateLimit-Remaining-Minute: 149

If you exceed these limits, we will return a 429 Too Many Requests error.

{ "message": "API rate limit exceeded" }

Our recommendations for working with rate limits

• Optimize your code to request only the data you need
• Analyze our response header metadata to monitor your usage
• Gracefully handle 429 status responses and build a retry mechanism with exponential backoff