This page describes how to authenticate to the Cash-In API Service (CIAS) and how to use it safely.
How requests are authenticated#
All requests to the Cash‑In API must include a valid access token in the request header. Tokens are issued separately for sandbox and production environments and are tied to a specific service and creditor account.curl -X GET "https://api.cash-in.com/v2/salesinvoices" \
-H "X-Api-Key: your-access-token" \
-H "Accept: application/json"
Use HTTPS for all requests to ensure secure transmission.
Tokens are valid only for the environment in which they were issued. Do not use a sandbox token in production.
Include the token in every request to authenticate successfully.
Invalid or missing tokens will result in 401 Unauthorized responses.
Transport security (HTTPS and TLS)#
Send all requests only over HTTPS to the base URL of the environment you are using, as listed on Environments. Configure your HTTP client to verify TLS server certificates (do not disable certificate verification in production).
IP address restrictions#
Since the service is open to the public internet, use of the API may be restricted by IP address for your integration.You must submit your IP address information to Cash-In IT before going to production with your API client. This is mandatory.
Plan for stable outbound IP addresses from your application (for example fixed egress in your cloud or data center). If your egress IPs change when you deploy or scale, coordinate updates with Cash-In IT before relying on those addresses in production.
Once your access token is validated and authorized, you can use all API endpoints available to your account.
Token lifecycle and rotation#
Obtaining access tokens#
Tokens are created separately for the production and sandbox environments.
We will produce both sandbox and production access tokens for you, and submit them to you in a secure PDF document for safe-keeping.
Partner integrations may use a partner master key for certain Confirma Software Partner operations, as documented on the relevant endpoints. Apply the same security practices as for standard API keys.
Store tokens securely and rotate them periodically to maintain best security practices.
Validation#
You can verify that a token is accepted with the Validate token endpoint. Renewal#
You can renew the access token with the Renew token endpoint. After renewal, update your secret store and deployments with the new token before retiring the old one.
Revocation and loss#
Treat tokens as compromised if they may have been copied into an insecure channel, committed to a repository, or used after staff departure without key rotation.
If a token is exposed, contact Cash-In immediately (see Reporting security incidents) and request revocation and re-issuance according to your agreement. Do not wait for a scheduled renewal if you suspect active misuse.
Operational best practices#
Use HTTPS for all requests to protect your token.
Rotate tokens periodically for security — use the Renew token endpoint to renew your access token. Limit token exposure to only the systems that need access.
Typical HTTP codes are summarized on Errors, including:| Code | Meaning (typical) |
|---|
| 401 Unauthorized | No valid API key, or the key is not accepted. |
| 403 Forbidden | The API key does not have permission to perform the request. |
Use these codes together with your logs (without including secrets) when troubleshooting integration issues.
Reporting security incidents#
If you suspect that an API key has been exposed, or you observe unexpected API activity, act promptly:Stop using the exposed credential in new deployments where you can do so safely.
Contact Cash-In IT Support about the incident. Do not include full API keys or passwords in email or tickets—state which environment (refer to Environments for naming) and approximate time range of the concern. Request key revocation and a new token if exposure is confirmed or likely.
Review IP allowlists and access to your own systems (CI, secret stores) that hold the key.
