Migrate from v1.x to v2.0
SDK v2.0 introduces breaking changes to the authentication API, the case model, and the exception hierarchy. This guide walks you through each change with before-and-after code samples.
SDK v1.x is not compatible with the v2 API. If you upgrade the SDK without updating your code, your application will throw exceptions at runtime. Test your upgraded integration in the Sandbox environment before deploying to production.
Migration checklist
- Update the SDK package:
pip install --upgrade caseforge-sdkornpm install @caseforge/sdk@2. - Update exception import paths —
CaseForgeAPIError→APIError. - Update the
case.typefield access tocase.case_type(Python) orcase.caseType(Node.js). - Replace
cases.fetch()calls withcases.get(). - Update code that treats
cases.list()as a plain list — it now returns an iterable. - Switch to OAuth 2.0 client credentials for production deployments (recommended, not required).
- Test all case creation, update, and close flows in Sandbox.
- Deploy to production.
Change 1 — Exception names
All exception class names have been simplified. The CaseForge prefix has been dropped. The module import path is unchanged.
Python
from caseforge.exceptions import (
CaseForgeAPIError,
CaseForgeRateLimitError,
CaseForgeNotFoundError,
)
try:
case = client.cases.get("case_abc")
except CaseForgeNotFoundError as e:
...
except CaseForgeAPIError as e:
...
from caseforge.exceptions import (
APIError,
RateLimitError,
NotFoundError,
)
try:
case = client.cases.get("case_abc")
except NotFoundError as e:
...
except APIError as e:
...
Node.js
import {
CaseForgeAPIError,
CaseForgeRateLimitError,
CaseForgeNotFoundError,
} from '@caseforge/sdk';
try {
...
} catch (e) {
if (e instanceof CaseForgeNotFoundError) {...}
}
import {
APIError,
RateLimitError,
NotFoundError,
} from '@caseforge/sdk';
try {
...
} catch (e) {
if (e instanceof NotFoundError) {...}
}
Change 2 — Case type field renamed
The type attribute on case objects is renamed to case_type (Python) / caseType (Node.js). This avoids shadowing Python's built-in type() function and improves clarity.
case = client.cases.get("case_abc")
print(case.type) # transaction_monitoring
case = client.cases.get("case_abc")
print(case.case_type) # transaction_monitoring
const c = await client.cases.get('case_abc');
console.log(c.type); // transaction_monitoring
const c = await client.cases.get('case_abc');
console.log(c.caseType); // transaction_monitoring
Change 3 — cases.fetch() removed
cases.fetch(), deprecated in v1.3, is removed in v2.0. Replace all calls with cases.get(). The signature is identical.
case = client.cases.fetch("case_abc")
case = client.cases.get("case_abc")
Change 4 — cases.list() returns an iterable
cases.list() now returns a lazy-paginating CasePage object instead of a plain list. In most situations the behavior is identical — you can iterate over it with a for loop. If your code accesses items by index or calls len(), wrap the result.
cases = client.cases.list(status="open")
first = cases[0] # worked in v1.x
total = len(cases) # worked in v1.x
cases = list(client.cases.list(status="open"))
first = cases[0] # works after list() conversion
total = len(cases) # works after list() conversion
If you're processing a large result set, iterate over the CasePage object directly rather than converting to a list. CasePage fetches subsequent pages on demand, which keeps memory usage constant regardless of result count.
Validate your migration
Run the following commands to confirm your integration works correctly against the Sandbox API after upgrading:
# Set a Sandbox key (prefix cf_sand_)
export CASEFORGE_API_KEY=cf_sand_your_key_here
# Run your test suite
pytest tests/integration/ -v
# Or run a quick smoke test
python -c "
import caseforge
c = caseforge.Client()
case = c.cases.create(subject_id='test_subj', case_type='transaction_monitoring', priority='low', summary='Migration smoke test')
print('Created:', case.id, case.case_type, case.status)
c.cases.update(case.id, status='closed', resolution='false_positive')
print('Closed OK')
"
When all integration tests pass against Sandbox, deploy to production. Monitor your error logs for any APIError or ValidationError exceptions during the first 24 hours — these indicate fields or patterns that need additional updates.