Skip to main content

API Changelog

History of the contract of the Collection Flow API v1: what exists today and how future changes will be versioned and communicated. Changes to endpoints, fields and behavior appear here in reverse chronological order (most recent first).

The canonical source of the contract is always the OpenAPI 3.1 specification (/openapi/openapi-v1-pt.yaml and the -en/-es variants). This changelog summarizes what changes between versions; the YAML has the field-by-field detail.

v1.0 — July 2026​

Public launch of the API v1. Contract baseline, with programmatic coverage of the entire collection operation that exists in the dashboard:

  • Portfolio — customers/debtors (people), classifications and contact interactions.
  • Charges — creation, update, lookup and manual notification triggering (charges).
  • Collection rules — multichannel rules (collection_rules), message templates (templates) and email layouts.
  • Agreements and disputes — payment agreements (agreements) and disputes (disputes).
  • Credit bureau and protest — bureau registration (negativations) and notarial protest (protests).
  • Operations — tasks (tasks), notifications (notifications), batch imports and exports.
  • Debtor portal — link generation and revocation.
  • Webhooks — signed endpoints (HMAC-SHA256), queued delivery with exponential retry and a delivery trail.

Conventions locked in at the baseline and covered by the compatibility guarantee below:

  • Stable error envelope { message, code, details? } — always branch on code.
  • camelCase responses, ISO 8601 (UTC) dates, monetary amounts as decimal strings.
  • API-key authentication with dunning.dashboard.<resource>.<action> scopes (see Authentication).
  • Idempotency via X-Idempotency-Key, page/per_page pagination and per-key rate limiting.

Versioning policy​

The API is versioned in the path (/api/v1). As long as the major version does not change, the contract only evolves in a backward-compatible way.

Backward-compatible changes (may happen at any time, without a new version)​

Your integration must tolerate these without breaking:

  • New endpoints and new resources.
  • New optional fields in responses — ignore the ones you don't recognize (don't do strict parsing that rejects extra fields).
  • New enum values and new error codes — handle unknown values with a fallback.
  • New optional query parameters and new response headers.
  • New webhook event types — subscribe only to the ones you handle and ignore the rest.

Breaking changes (require a new major version, e.g. /api/v2)​

Never applied silently to v1:

  • Removing or renaming endpoints, fields or error codes.
  • Changing the type or meaning of an existing field.
  • Making a previously optional parameter required.
  • Tightening validation rules so a previously valid request starts failing.

How changes are communicated​

  • Additive changes land in the OpenAPI specification and are recorded in this changelog, dated.
  • Deprecations are announced here and in the changelog ahead of time, keeping the old behavior working throughout the transition period before any removal (which only happens in a new major version).
  • We recommend watching this page and subscribing to webhooks to react to new events.