API responses

Successful responses share one JSON shape: a version, a resource type, and the payload in `data`.

Common format

Every response uses the same structure:

Common data format

{
  "version": "1.0",
  "resource_type": "<the resource type here>",
  "data": { ... }
}

• version – Indicates the version of the response format. While not strict Semantic Versioning (SemVer), it reflects whether the change is breaking or additive.
• resource_type – Identifies the type of resource returned (e.g. agreement, participant, etc.).
• data – Contains the primary payload of the response.

Supported response types

Single resource

A single object representing the requested resource.

Single resource

{
  "version": "1.0",
  "resource_type": "<resource_type>",
  "result_type": "single",
  "data": { ... }
}

List resource

An array of resource objects, without pagination.

The list resource

{
  "version": "1.0",
  "resource_type": "<resource_type>",
  "result_type": "list",
  "data": [ ... ]
}

Paginated list

A list of resources returned in pages, including metadata for pagination.

The paginated list resource

{
  "version": "1.0",
  "resource_type": "<resource_type>",
  "result_type": "paginated_list",
  "pagination": {
    "limit": 25,
    "page": 1,
    "total_results": 250,
    "total_pages": 10
  },
  "data": [ ... ]
}

Deleted resource

Confirms that a resource has been deleted. The data field contains a snapshot of the deleted object.

The delete resource

{
  "version": "1.0",
  "resource_type": "<resource_type>",
  "result_type": "deleted",
  "data": { ... }
}

Webhook event

Delivered asynchronously when something important happens. Includes event metadata and the resource payload.

The webhook event resource

{
  "version": "1.0",
  "resource_type": "<resource_type>",
  "event": "<event_name>",
  "request_timestamp": "<ISO 8601 timestamp>",
  "data": { ... }
}

Versioning and compatibility

Zigned uses a pragmatic approach to response versioning:

• Major changes introduce a new version value in the response payload.
• Additive changes (such as new fields or nested objects) are made within the same version and do not break existing integrations.
• No silent removals – once a key is introduced in a version, it will not be removed or renamed within that same major version.

To maintain compatibility across changes:

• Your client should ignore unknown fields in the response.
• Monitor the version field to detect changes that may require review.
• Refer to the changelog for a detailed history of updates.

Summary

The same shape is used for a single resource and for a longer signing flow. Ignore fields you don't know, and check version when you want to see if the format changed.