DevenConnect — v1.2.0 Migration Guide

This guide covers the two changes in v1.2.0 that affect API integrations, and how to migrate at your own pace.

Change 1 — Property Naming: PascalCase → camelCase

What's changing

Starting in v1.2.0, all JSON property names in API responses use camelCase (dealName, targetId) instead of PascalCase (DealName, TargetId).

Why this benefits you

camelCase is the standard convention for JSON APIs and the native expectation of virtually every modern HTTP client, SDK generator, and serializer across JavaScript/TypeScript, Python, Java, and beyond. This eliminates the need for custom naming policies or property-mapping shims just to consume our data — your deserialized objects will align naturally with your language and framework conventions.

What you need to do

Update property name references in your integration code. This is typically a find-and-replace operation within your API client models or deserialization mappings. If you generate a client from our OpenAPI spec, regenerating against the v1.2.0 spec is sufficient.

Example: response.DealName → response.dealName

This affects response payloads only — request bodies are not impacted.

Refer to the interactive API reference for updated response schemas: https://{tenant}.devensoft.com/api/core/swagger/

Change 2 — Default JSON Response Shape & Media Types

What's changing

In v1.2.0, the default JSON response structure begins a versioned transition. The current response shape remains the default for now; a Collection+JSON–based structure will become the default in a future release. You control the pace of your migration entirely via the Accept request header.

Supported media types

Accept header value	Status	Response shape
`Accept: application/json` (or omitted)	DEFAULT	Current shape — default today; unchanged. No deprecation applies.
`Accept: application/json;version=1`	SUPPORTED	Explicitly pins the current JSON structure. Recommended for integrations that want insulation from future shape changes.
`Accept: application/vnd.devensoft.collection+json`	PREFERRED	Vendor Collection+JSON — spec-compliant hypermedia envelope (`collection.items`, `collection.links`, `collection.queries`). This is the future-proof target type and never carries deprecation headers.
`Accept: application/vnd.devensoft.collection+json; profile="https://devensoft.com/profiles/pragmatic"`	PREFERRED	Pragmatic variant — same envelope, but each item's `data` is a flat key/value object matching familiar JSON property structure.
`Accept: application/vnd.collection+json`	DEPRECATED	Standard (IANA) Collection+JSON type. Still fully functional during the support window, but responses carry deprecation signaling headers (see Change 3). Migrate to the vendor type.
`Accept: application/vnd.collection+json; profile="https://devensoft.com/profiles/pragmatic"`	DEPRECATED	Pragmatic variant of the standard type. Functional, carries deprecation headers. Migrate to the vendor type.

_{Note on the profile parameter: the canonical form is the URI profile="https://devensoft.com/profiles/pragmatic" (RFC 6906). The older bare-token form profile=pragmatic is still accepted for backward compatibility, but responses will always echo the URI form. New integrations should use the URI form.}

How versioning works

The version parameter is honored on application/json and every +json-suffixed media type — including both Collection+JSON types. For example: Accept: application/vnd.devensoft.collection+json; version=1. The resolved version is echoed back in the response Content-Type, so you can confirm what the server applied. In v1.2.0 all versions serialize identically; the parameter exists so you can pin ahead of any future divergence.

Change 3 — Deprecation Signaling Headers (new)

So that deprecation is machine-detectable, responses served with the deprecated standard type application/vnd.collection+json now include these response headers (per RFC 8594):

Deprecation: true
Link: <https://developers.devensoft.com/api/media-types>; rel="deprecation"

These headers appear on success and error responses alike, and never appear on responses served with the vendor type or application/json. We recommend logging any response carrying a Deprecation header in your integration so you can identify remaining call sites still using the standard type.

What you need to do — migrate at your own pace

Nothing is required immediately. The current response shape remains the default, and your existing integration continues to work unchanged. When you are ready, we recommend this self-paced sequence:

Today (zero code impact): make your Accept header explicit — Accept: application/json; version=1. This pins your current contract in one centralized place (base HTTP client, request interceptor, or default headers config) and insulates you from any future default switch, on your schedule.
Evaluate (any time): preview Collection+JSON responses using the Swagger UI at https://{tenant}.devensoft.com/api/core/swagger/ by sending the vendor Accept header and inspecting the envelope.
Adopt (when ready): switch your Accept header to application/vnd.devensoft.collection+json (optionally with ; profile="https://devensoft.com/profiles/pragmatic" for flat data objects). Update your response parsing to the collection envelope. This is a one-time, client-side parsing change — schedule it like any other sprint item.
Verify: confirm your integration receives no Deprecation response headers — that is your confirmation you are fully on the target state.

_{For customers using query parameters such as modifiedSince for delta sync: these continue to work identically regardless of media type. Media type selection changes only the response shape, never filtering behavior.}

Support window

The deprecated standard type (application/vnd.collection+json) remains supported for 6 months after the default shape switches. We will communicate the default-switch date with advance notice ahead of that release, so your pinned or migrated integrations are never caught by surprise.