Connect your application to a GraphOps service with an API key. Use separate keys for each product, environment, and application so you can see which workload uses credits and replace one credential without touching the others.
Open API keysCreate a key
You need the owner or developer role.
- Open API keys in the organization that should pay for the usage.
- Choose the product, such as RPC, Subgraphs, or Substreams.
- Give the key a label that names its workload and environment, such as
production-indexer. - Copy the key into your secret manager when it is shown. You cannot retrieve the same key again.
To connect right away, choose Get query endpoint after saving the key. You get the endpoint, authentication header, and example code for the new key without pasting it again.
If creation reports Data services unavailable, select Retry to load the products you can choose. Your label stays in the dialog while you refresh.
Use a saved key
When setting up an endpoint, paste the key from your secret manager. If the dialog reports API keys unavailable, select Retry to load your organization's keys before continuing. Your pasted key stays in the dialog during refresh; closing the dialog clears it.
Each service's authentication page shows the header or URL format it expects.
Understand key access
A key works for one product in one organization. It does not grant access to other products or other organizations.
| Property | Behavior |
|---|---|
| Organization | Usage is billed to and limited by the organization that created the key. |
| Product | The key works only for the product chosen at creation. |
| Label | Identifies the environment, owner, or workload in API keys and Usage. |
| Visibility | The plaintext key is shown once, at creation. GraphOps cannot show it again. |
| Expiry | Keys have no expiration date by default. Plan rotation yourself. |
| Active keys | Your plan sets how many active keys the organization can have. Revoke unused keys. |
Rotate and revoke
Choose the replacement path by whether the old key must keep working during the change:
- Planned replacement: create a second key for the same product, deploy it to the workload, confirm traffic succeeds, then revoke the old key. The workload has no gap in access.
- Exposed key: choose Rotate API key. The old key stops working immediately, and a new key for the same product and label is shown once. Deploy it to the affected applications.
Revocation is permanent: any request that still uses a revoked key fails.
Manage API keysFind unused keys
Check Last used in API keys. It shows the most recent UTC date with settled usage for each key, such as yesterday or 3 days ago within the past week, or Never. The date updates when usage settles, so recent requests can take some time to appear. A rotated replacement starts at Never, and the replaced key keeps its date.
Revoke keys that no longer receive traffic instead of leaving them available.
Permissions
Owners and developers can create, rotate, and revoke API keys. Billing admins and viewers cannot see or manage API keys. See Team and roles for every role.
Security checklist
- Store keys in a secret manager or server-side runtime configuration.
- Keep keys out of source code, issue trackers, support messages, and client-side bundles.
- Use separate keys for development, staging, production, and each product.
- Use labels that make ownership obvious during incident response.
- Rotate a key before changing ownership or after a suspected exposure.