Build for Backwards Compatibility
The Nitro Sign API is designed to remain backwards compatible rather than rely on versioning. This approach helps you avoid costly migrations and ensures that once a feature is released, it will continue to work as expected. As a general rule:- New functionality will be introduced as optional parameters or additional response fields.
- Existing behavior will not change or break if you do not use these new fields.
- Do not enforce strict schema validation on API responses. The API may return new fields that your current implementation does not expect.
- Safely ignore any new response fields you are not using in your integration.
Use the Error Glossary
The Sign API documentation includes an Error Glossary that explains common and Nitro-specific errors you may encounter. Error responses include direct links to the relevant glossary entries, making it easier to identify issues and apply the right fix.Keep Rate Limits in Mind
To maintain service availability and fair use of resources, the Sign API enforces rate limits on all endpoints. When designing recurring or automated operations, ensure you respect these limits to avoid down time for your application. This helps us trace and troubleshoot requests more effectively. In the event of a support ticket, providing these IDs allows Nitro’s team to investigate and resolve issues faster.Cache Access Tokens
You should store access tokens in a temporary cache or your database so you can reuse it while still valid. A common approach is to store the token in an in-memory cache like Redis, setting its expiry to match theexpiresIn
value returned by the API. This ensures the token is automatically invalidated when it expires. Alternatively, you can store it in a database and implement custom logic to update it.