Authentication · Environments
Sandbox and Production environments
Planned: build and validate safely in Sandbox, then promote the same integration to Production with separate URLs, credentials, and operational controls.
Separate sandbox and production environments is coming soon
This page previews the planned design. It is not available in the API yet, so the examples below will not work against it today.
What exists today
There is one API host and one environment. Use the same credentials flow everywhere: enable POS to get a Client ID and public key (see API keys), authenticate for a token (see Access token), and call /api/v1/... on this host.
https://api.uat.einvoicing.avetiumtechnologies.com/api/v1The planned design
Environment isolation is intentional
Credentials, access tokens, and invoice data should never cross environments. Treat a switch as a controlled deployment, not a configuration toggle in a client.
Choose the right environment
Sandbox · Selected
Build and test
Simulated delivery and non-production invoice data.
Production · Locked
Serve customers
Live compliance flows after access approval.
Show the selected environment beside every credential, URL, and code example. Persist it server-side and use a visible confirmation before any Production action.
Base URLs and credentials
https://[sandbox-host]/api/v1https://[production-host]/api/v1Never reuse credentials
Plan for environment-specific POS credentials and request new access tokens after switching. The hosts above are placeholders until environments are available.
How environments differ
| Attribute | Sandbox | Production |
|---|---|---|
| Purpose | Integration testing | Live invoicing |
| Data | Synthetic or test data | Real customer data |
| Delivery | Simulated outcomes | Live network delivery |
| Credentials | Self-service POS credentials | Approved POS credentials |
| Support | Best-effort testing | Operational monitoring |
Test data behavior
Use fictional recipients, deterministic amounts, and non-routable addresses. Sandbox records may be reset and do not create legally valid invoices or reach live recipients.
Keep personal data out of Sandbox
Do not copy live invoice payloads, customer identifiers, or tax numbers into test fixtures.
Switch environments safely
Once environments exist, drive the base URL and credentials from server-side configuration. Redeploy the service, request a fresh token, then run a read-only call before enabling writes.
Safe configuration pattern
# planned, not available yet
EINV_BASE_URL=https://[production-host]
EINV_CLIENT_ID=[organization_reference]Production access requirements
Production access is representative and subject to workspace policy. Expect an approved business profile, completed compliance review, verified sending identity, named technical owner, and an operational callback endpoint.
Request access before your launch window
Allow time for review and credential issuance. Keep Sandbox available for regression testing after approval.
Readiness checklist
- All automated tests pass against Sandbox
- No real customer data or Production secrets are used in Sandbox
- Production owner and alerting are approved
- Callback URL is https and reachable
- Rollback plan and post-deployment checks are documented
Promote to Production
Promote configuration, not data. Keep the tested request schema, replace only environment-bound values, and verify with a low-risk first transaction.
1. Validate in Sandbox
Pass happy paths, failures, and callback delivery.
2. Complete access review
Confirm ownership, alerting, and support contacts.
3. Deploy Production configuration
Install the live URL and POS credentials in the secret store.
4. Verify and monitor
Request a new token, send one controlled invoice, and inspect the result.
Ready means observable
Confirm token requests, invoice writes, callback delivery, error rates, and rollback ownership before opening customer traffic.