Platform
API Versioning
Understand how NextSign versions endpoints and how to safely work with both v2 and v3 routes.
API Versioning
NextSign versions its API in the request path. Integrate against the exact version documented for each endpoint instead of assuming all resources exist in the same version.
Current Versioning Pattern
The current documentation uses URL-based versioning:
https://www.nextsign.dk/api/v2/...
https://api.nextsign.dk/v3/...Examples from the current API surface:
- Cases and forms are primarily documented under
v2 - Newer file endpoints such as upload and view-presigned-url are documented under
v3
Do not try to upgrade an endpoint by changing only the version segment in the URL. Treat each documented path as its own contract.
What This Means for Integrations
- Pin the full endpoint URL in your client code
- Keep tests for each version you depend on
- Expect request and response behavior to differ between older and newer endpoints
- Validate both HTTP status codes and response bodies on older
v2endpoints
Recommended Strategy
When building or updating an integration:
- Use the exact endpoint path from the docs
- Keep
v2andv3routes separate in code - Test version changes in the test environment before switching production traffic
- Review request examples and error handling for the specific endpoint you call
Common Mistakes to Avoid
- Assuming every file endpoint is under
v2 - Assuming every newer endpoint also has a
v2equivalent - Using a single global version variable for all NextSign requests
- Skipping regression tests when moving from one versioned route to another
Commonly Used Examples
- Case Create uses
POST /api/v2/{company}/case/create - Forms Submit uses
POST /api/v2/{company}/forms/{form_id}/submit - Document Upload uses
POST /v3/company/{company}/file/upload - Document Retrieve uses
POST /v3/company/{company}/file/view-presigned-url