Developer API Setup
Create a least-privilege Eigenn credential, check it against public API v1, and prepare safe writes.
This setup produces a server-side credential for Eigenn's public API. Eigenn scopes an API key to the team. Eigenn shows the key one time only, when you create it.
Before You Start
- Select the team that the integration must get access to.
- Use a workspace owner account to create or revoke team API keys.
- Confirm that the team's plan permits another API key.
- Decide whether the integration needs production or sandbox.
- List the exact resources and actions that the integration needs.
1. Create a Restricted Key
- Open Settings → Developer.
- In API Keys, select Create API Key.
- Enter a name for the service and the environment.
- Choose an access preset:
- All grants all public read and write scopes.
- Read Only grants every readable public scope.
- Restricted lets you select resource-specific read or write scopes.
- Select Restricted. We recommend this preset.
- Select only the necessary scopes.
- Select Create.
- Copy the key immediately.
The full secret is visible only in the creation confirmation. If you lose it, create a replacement. Do not try to recover it.
2. Store the Key
Store the credential in a server-side secret manager. Do not put it in:
- browser code
- a mobile application bundle
- source control
- build logs
- analytics events
- screenshots or support tickets
Use a separate key for each service and environment. Then you can rotate one credential without a disruption to unrelated integrations.
3. Choose the Base URL
| Environment | Base URL |
|---|---|
| Production | https://api.eigenn.io/v1 |
| Sandbox | https://api-staging.eigenn.io/v1 |
In the current public contract, the sandbox environment runs on the api-staging host. Do not use it as evidence of production state.
4. Confirm Authentication
A restricted key with users.read can call the current-user endpoint:
curl --request GET \
--url https://api.eigenn.io/v1/users/me \
--header "Authorization: Bearer $EIGENN_API_TOKEN" \
--header "Accept: application/json"A successful response returns the authenticated user profile. It does not return the secret.
Interpret failures as follows:
- 401: the Authorization header or credential is absent, invalid, expired, or not bound to an accessible team
- 403: the credential is valid but lacks users.read
- 429: wait for the Retry-After interval before you try again
5. Examine the Contract
Use the API Reference for interactive exploration or fetch the machine-readable document from:
https://api.eigenn.io/v1/openapi
Check each operation for:
- HTTP method and endpoint
- the necessary scope
- the necessary request fields
- status-specific response schemas
- pagination limits
- Idempotency-Key support
Do not infer an endpoint from a product page. Product capabilities such as workflow management can exist without a public API operation.
6. Prepare Writes
Before the first write:
- Test the same request in sandbox with representative data.
- Choose a stable idempotency key for the logical write.
- Keep the key at 128 characters or fewer.
- Check the response before you start dependent work.
- Log the status, the request ID when available, and the idempotency status.
Example customer creation:
curl --request POST \
--url https://api.eigenn.io/v1/customers \
--header "Authorization: Bearer $EIGENN_API_TOKEN" \
--header "Content-Type: application/json" \
--header "Idempotency-Key: customer-acme-2026-07-11" \
--data '{
"name": "Acme Corporation",
"email": "[email protected]"
}'The key needs customers.write. A customer create request can upsert a record that already matches. Examine the customer ID in the response. Do not assume that every successful request created a new row.
7. Rotate Safely
- Create a replacement with the same or narrower scopes.
- Deploy the replacement to the service that uses it.
- Confirm a read and one safe write when necessary.
- Revoke the old key from Settings → Developer.
- Check 401 responses and integration health.
Revocation is team-wide. It takes effect for future authenticated requests. Keep credentials separate enough that rotation has a clear owner.