Docs/Help/Security

Security

Protect your Voyced credentials, customer information and workflow history at every stage.

Why this matters

A person or system with your credentials may use the Voyced functions allowed for that key. Good storage, limited permissions and fast rotation reduce that risk without making normal development difficult.

Protect both sides of the connection

Voyced protects the API service. You protect the credentials after they are issued and the systems where you use them. Anyone who obtains valid credentials may use the functions allowed for that key until it is rotated or disabled.

Understand each credential

Credential	Use	How to protect it
API key	Identifies the integration.	Keep it with the matching secret. Do not treat it as proof of access by itself.
API secret	Requests a temporary bearer token.	Treat it like a password. Store it server-side in a secret manager or protected configuration.
Bearer token	Authorises API calls for a limited time.	Keep it in memory where possible. Never place it in a URL or a shared log.

Required security checklist

Keep Sandbox and Live credentials separate. Give each integration only the permissions it needs. Store secrets outside source code and outside the public web folder. Exclude secret files from Git, backups shared with others and workflow exports. Use HTTPS and keep certificate checks enabled. Remove complete Authorization headers and tokens from logs. Restrict who can view workflow history and execution data. Disable credentials that are no longer used.

Never place credentials here

Client-side code

Do not put secrets in browser JavaScript, mobile apps or downloadable files.

Shared records

Do not include credentials in screenshots, tickets, emails, chat messages or public repositories.

URLs and logs

Do not use credentials in query strings or record complete request headers and bodies.

Sandbox still needs full protection

Sandbox reduces the risk of changing a Live service. It does not make credentials or returned information public or disposable. Protect Sandbox credentials and data to the same standard as Live.

Do not assume Sandbox data is anonymous.
Keep only the test data you need.
Remove downloaded responses and completed test files when the test is finished.
Never reuse Sandbox credentials in Live.

Automation and API tools

Tool	Security action
Postman	Use Secure local environment values. Do not share credential values with a workspace or export a filled environment.
Zapier	Use a controlled workspace. Restrict who can edit the Zap and review what request data appears in task history.
Make	Use protected credentials or keychain storage where supported. Review scenario history before enabling Live.
n8n	Use your approved credential or secret-management method. Restrict workflow exports and execution-data access.

When exposure may have happened

Stop the integration or remove the exposed value from public access.
Replace the credential in every dependent system before restarting the integration.
Rotate the API secret or disable the affected API key.
Update the protected credential in the integration.
Review recent API activity and workflow logs.
Test again in Sandbox before restoring normal Live traffic.

Do not wait for proof of misuse

Rotate a credential when you believe it may have been copied, logged, committed or shared. Early rotation is safer and normally faster than investigating first.

Logging

Record the environment, method, endpoint, HTTP status, UTC time and Voyced request ID. Remove or mask:

API secrets
Bearer tokens
Complete Authorization headers
Customer information that is not needed for support

Documentation Sandbox tester

The built-in tester accepts temporary Sandbox bearer tokens only. It does not accept API keys or API secrets, cannot call Live and does not store the token in cookies, browser storage or the page URL.