Overview

API security is an important part of protecting automated integrations between SPRL and your applications, websites, internal systems, or business workflows.

API credentials can provide access to SPRL functionality and should therefore be treated as sensitive information. A compromised API credential may allow unauthorized users or applications to perform actions through your account.

Protect Your API Credentials

API keys, access tokens, and other authentication credentials should be treated with the same care as account passwords.

• Store API credentials securely.
• Never share credentials with unauthorized users.
• Do not include private credentials in public repositories.
• Do not expose private credentials in browser-side code.
• Do not include credentials in screenshots or support requests.
• Replace credentials if you believe they have been exposed.

Keep API Credentials Server-Side

Private API credentials should generally be used from a trusted server-side environment rather than being embedded directly in frontend JavaScript or other publicly accessible application code.

If a credential is included in browser-side code, users may be able to inspect the application and obtain the credential.

Use Environment Configuration

For server-side applications, credentials should be stored outside application source code whenever practical.

Use your application's secure configuration or environment-management mechanism to provide credentials to the application at runtime.

• Keep credentials outside publicly accessible source files.
• Restrict access to configuration files.
• Do not commit secrets to source-control repositories.
• Use separate credentials for different environments where appropriate.
• Protect production credentials from development environments.

Protect API Requests

API requests should be made over secure connections and should be handled carefully by your application.

• Use HTTPS when communicating with SPRL APIs.
• Validate API responses before processing them.
• Handle errors without exposing sensitive information.
• Avoid logging credentials or authorization headers.
• Protect application logs and monitoring systems.

Validate API Responses

Applications should not assume that every API request will succeed. Your integration should correctly handle successful responses, validation errors, authentication failures, unavailable services, and other unexpected responses.

• Check HTTP status codes.
• Validate response data before using it.
• Handle authentication failures appropriately.
• Handle invalid request responses.
• Prevent unexpected responses from breaking business workflows.

Handle Errors Securely

Error messages and logs should provide enough information for troubleshooting without exposing sensitive credentials or internal security information.

Avoid displaying raw technical information to end users when it could expose confidential implementation details.

Prevent Duplicate API Operations

Applications that automatically retry failed requests should be designed carefully to avoid unintentionally performing the same operation multiple times.

For operations that create or modify resources, consider how your application handles network failures and retry conditions before automatically repeating a request.

• Identify operations that could create duplicates.
• Implement appropriate retry controls.
• Handle network timeouts carefully.
• Verify the result of an uncertain request before repeating it.
• Test retry behavior before production deployment.

Secure API Integrations

Enterprise applications may connect SPRL with websites, internal systems, marketing workflows, analytics platforms, or other business applications.

Each integration should be reviewed as part of your organization's security architecture.

• Document applications that use SPRL APIs.
• Identify who is responsible for each integration.
• Store credentials securely.
• Review integrations periodically.
• Remove unused integrations.
• Investigate unexpected API activity.

Development & Testing

API integrations should be tested before being deployed to production.

Use appropriate development or testing environments and avoid exposing production credentials during development.

• Do not use production credentials unnecessarily during development.
• Keep test credentials separate where applicable.
• Remove test credentials that are no longer required.
• Test authentication and error handling.
• Test network failures and unexpected responses.
• Review application logs for accidental credential exposure.

API Credentials & Team Access

Organizations should control which users and applications have access to API credentials.

• Limit access to authorized developers and administrators.
• Avoid sharing API credentials between unrelated applications.
• Document important integrations.
• Review access when employees or responsibilities change.
• Remove credentials that are no longer required.

What to Do If an API Credential Is Exposed

If an API key or other credential is accidentally exposed, assume that it may have been accessed by an unauthorized party.

1. Stop using the exposed credential where possible.
2. Replace or deactivate the credential where applicable.
3. Review recent API activity.
4. Check connected applications and workflows.
5. Investigate unexpected requests or changes.
6. Remove the exposed credential from source code and configuration.
7. Review source-control history if the credential was committed.
8. Contact SPRL Support if assistance is required.

API Security Monitoring

Regular monitoring can help organizations identify unusual API activity and investigate potential integration problems.

Depending on your application and monitoring capabilities, consider reviewing:

• Unexpected API requests.
• Authentication failures.
• Unusual request volumes.
• Unexpected application behavior.
• Changes to connected integrations.
• Unexpected link or resource creation.

API Security Best Practices

API Security Checklist

Frequently Asked Questions

Where should I store my SPRL API credentials?

Store private API credentials in a secure server-side or trusted application environment. Avoid placing them directly in frontend code or publicly accessible files.

Can I put my API key in JavaScript?

Private API credentials should not be exposed in browser-side JavaScript because users may be able to inspect the code and retrieve the credential.

Can I commit my API key to Git?

No. Private API credentials should never be committed to public repositories. If a credential has already been committed or exposed, treat it as compromised and replace it.

Should API keys be included in application logs?

No. API keys, passwords, access tokens, and authorization headers should not be stored in application logs.

What should I do if my API key is exposed?

Secure or replace the affected credential where applicable, review API activity, investigate unexpected requests, and contact SPRL Support if assistance is required.

Should I use production API credentials during development?

Avoid using production credentials during development unless necessary. Keep development and production credentials appropriately separated.

How should I handle API errors?

Validate responses, handle HTTP errors appropriately, and ensure that error messages and logs do not expose sensitive credentials or unnecessary confidential information.

How often should API integrations be reviewed?

Review integrations periodically and whenever applications, users, credentials, or business requirements change.

Quick Reference