Clarified that expiration_date stops data access without changing the agreement status
Released 15th October 2026This patch release clarifies the behaviour of the expiration_date field across all share agreement endpoints. No functional API behaviour has changed.
Patch Release: Documentation-only changes that clarify existing expiration behaviour. No breaking changes or functional modifications.
POST /v2/orgs/tms-share-agreements/{tms_share_agreement_id}/activate
POST /v2/orgs/tms-share-agreements/{tms_share_agreement_id}/cancel
POST /v2/orgs/tms-share-agreements/{tms_share_agreement_id}/pause
What changed:The description of the expiration_date field has been updated to accurately reflect that data access stops at the expiration time but the agreement’s status field is not automatically changed to EXPIRED.Before:
When data access ends. Null means no expiration.Status automatically changes to EXPIRED after this date.
After:
When data access ends. Null means no expiration.Access stops at this time even though the status stays unchanged.
Impact:
No changes to API behaviour
Existing integrations are unaffected
If your code checks status == "expired" to detect expired agreements, note that the status is not updated automatically — use expiration_date directly to determine whether access has lapsed
If you need to know whether a share agreement’s data access has ended, compare expiration_date against the current time rather than relying on the status field:
from datetime import datetime, timezonedef is_access_expired(agreement): if agreement["expiration_date"] is None: return False expiry = datetime.fromisoformat(agreement["expiration_date"]) return expiry < datetime.now(timezone.utc)
2
No action required for most integrations
This is a documentation-only update. If your integration is currently working, no changes are needed.
