Developer API Keys

API keys authenticate requests to Seev API products. In the Developer Dashboard, keys are created per product and per environment, so you can separate sandbox and production access.

How product keys work

Each Seev API product is backed by a separate service. When you generate a key, choose the product the key belongs to:

Because products are separate services, each product has its own keys. A merchant may also create multiple keys for the same product, for example one Checkout API key for a web app and another Checkout API key for a mobile app.

Authenticate requests

Use the API key generated for the product and environment you are calling. Send it from your server when making requests to Seev.

POST /api/v1/developer/payments HTTP/1.1
Host: api.seevplus.com
Authorization: Bearer <your_checkout_api_key>
Idempotency-Key: order_123_attempt_1
Content-Type: application/json

Idempotency-Key is optional for checkout payment initiation, but recommended for deliberate retries. X-API-Key: <your_checkout_api_key> may be used instead of the Authorization header.

Generate a key

1. Open Seev API -> API Keys.
2. Click Generate Key.
3. Select the product you want to generate the key for.
4. Enter a key name that describes where it will be used.
5. Optionally enable IP whitelisting.
6. Click Create Key.

Good key names are specific to the app or service using them, for example:

IP whitelisting

IP whitelisting restricts where a key can be used from. When enabled, only requests from the IP addresses you provide should be accepted for that key.

Use IP whitelisting for server-side integrations where your outbound IP addresses are stable. Avoid enabling it for environments where IP addresses change frequently unless you can keep the list updated.

Environments

Keys are environment-specific:

When you switch the developer environment in the dashboard, the API Keys tab shows keys for the selected environment.

Production access requires approved organization verification. Sandbox keys remain available for building and testing without moving live money.

Public and secret keys

New keys can return both a public key and a secret key. The full secret key is displayed only once, immediately after creation or rotation. Copy it into a secure secrets manager before closing the confirmation screen.

The API Keys table later shows the public key and a masked secret-key prefix so you can identify the credential without exposing it.

If you close the view-once screen without saving the secret, Seev cannot display that same secret later. Generate or rotate a key and update your application with the newly shown value.

Rotate a key

Rotate a key when a secret may have been exposed, when access changes, or as part of your credential policy. Rotation revokes the old Dashboard key record and creates a replacement. The replacement secret is shown once.

Update the application using the key before removing any remaining dependency on the previous credential.

A safe rollout is:

1. Rotate the key and copy the new secret.
2. Update the application secret store.
3. Deploy and confirm sandbox or controlled production requests succeed.
4. Remove old environment variables and secret copies.

Delete a key

Deleting a key removes it from the selected environment. Confirm that no deployed application still depends on it before deleting it. Use separate keys for separate applications so one app can be rotated or removed without interrupting another.

Store keys securely

Store API keys in environment variables or a secrets manager such as AWS Secrets Manager, HashiCorp Vault, Doppler, or your hosting provider's secret store. Load keys at runtime and keep separate keys for sandbox and production.

# .env (local development only)
SEEV_CHECKOUT_API_KEY=your_sandbox_or_production_key

# .env.example (safe to commit)
SEEV_CHECKOUT_API_KEY=

• Do not commit .env files
• Do not hard-code keys in configuration files
• Do not print keys in logs and error reports.

Authentication errors

If a request is rejected with 401 Unauthorized, check that:

• The request includes the API key.
• The key belongs to the product you are calling.
• The key belongs to the selected environment.
• The key is active and has not been revoked or disabled.
• The key value does not include extra whitespace.

If IP whitelisting is enabled, also confirm that the request leaves your server from an allowed public IP address.

Before going live

• Use a new production key rather than reusing sandbox configuration.
• Give each deployed app or backend its own named key.
• Add IP restrictions only when outbound addresses are stable.
• Verify payments on the server; a browser redirect alone is not proof of payment.
• Configure signed webhooks for asynchronous updates.
• Know how you will rotate the key without downtime.

Related docs

• Checkout API
• Developer Transactions
• Errors and codes