Start in Sandbox
Start every integration in Sandbox. It gives you a safe place to prove the full request flow before Live access is enabled.
Protect your Voyced access from the first test
Your API credentials can access customer information and the functions allowed for that key. Treat the API secret like a password. Store it only in protected server-side settings or a trusted secret store.
- Never put an API key, API secret or bearer token in public code, browser JavaScript, screenshots, URLs or support messages.
- Keep Sandbox and Live credentials separate. Give each integration only the permissions it needs.
- Rotate the secret and disable the old key at once when exposure is suspected.
Start here
Sandbox
https://sandbox.voycedconnect.eu/v1
Build and check your integration without using Live credentials.
After approval
Live
https://api.voycedconnect.eu/v1
Use only after your tests pass and Voyced has enabled Live access.
One safe rule
Build, test and fix everything in Sandbox first. Move only a tested integration to Live, and only after Voyced has enabled Live access.
Sandbox is not public or disposable
It protects Live workflows from test changes, but its credentials and returned information still need the same care as Live. Do not share responses, completed test files or screenshots containing customer information.
Why start in Sandbox?
- You can confirm authentication without using Live credentials.
- You can test error handling, token expiry and rate-limit behaviour.
- You can check which permissions are available to your key.
- You can prove how your app stores secrets and logs requests.
- You can find mistakes before they affect a Live workflow.
Sandbox data
The information available in Sandbox depends on the access configured for your Sandbox key. Do not assume that Sandbox and Live contain the same data.
Use these Sandbox settings
| Setting | Sandbox value |
|---|---|
| Base URL | https://sandbox.voycedconnect.eu/v1 |
| API key | Your Sandbox API key |
| API secret | Your Sandbox API secret |
| Bearer token | Request it from the Sandbox token endpoint |
| Permissions | Check GET /v1/capabilities |
What to test
Successful requests
Token, connection test, capabilities, customer, numbers and balance.
Failed requests
Missing token, expired token, missing permission, unknown number and rate limit.
Safe handling
Secrets stay out of source code, URLs, logs and screenshots.
Recovery
Your app requests a new token and retries only when it is safe.
Minimum pass checks
| Check | Pass result | What a failure means |
|---|---|---|
| Request token | HTTP 200 with data.access_token | Check the Sandbox URL and Sandbox credentials. |
| Connection test | success: true | The token worked, but customer access or service data needs checking. |
| Capabilities | Needed functions show true | The key does not have every required permission. |
| Telephone numbers | Expected active numbers are returned | Check the customer access assigned to the key. |
| Error handling | Your integration handles 401, 403, 429 and 5xx safely | Do not move to Live until failures are controlled. |