Skip to main content
Nitro follows REST principles along with additional guidelines in the development of the Sign API. Below are recommended practices and concepts to help you design integrations that remain reliable and adaptable over time. Following these guidelines will make your integration with the Nitro Sign API more stable and easier to maintain.

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.
Best practices for your application:
  • 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 the expiresIn 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.
I