Skip to main content

Changelog

This page tracks every change to the public RCM API contract — new endpoints, deprecations, breaking changes, and notable additive updates.

The format is reverse chronological (newest first) and follows the spirit of Keep a Changelog.

Unreleased​

Added​

  • GET /v1/accounts/base-accounts/origin-events/{originEventId}/deep-info — read the full state of the base account(s) behind one encounter by the origin_event_id your HIS sent: status, payer, invoice, agreement and plan coverage, concurrent-audit flags, plus nested events and support files. Already available in the API; only now documented. See Get deep base account information.
  • Integration Events pull API — POST /v1/integration/events/pull, POST /v1/integration/events/ack and GET /v1/integration/events/stats are now in the reference under the Integration Events tag. This is the pull-based alternative to push webhooks, and the channel through which RGA audit events are consumed. Already available in the API; the reference was missing it. Batch size is capped server-side at 50.
  • HTTP Basic authentication for webhook subscriptions is now in the reference — auth_type (HMAC by default, or BASIC), basic_auth_client_id and basic_auth_client_secret on create and update, and auth_type / basic_auth_client_id on the subscription resource. The secret is stored encrypted and never returned. The behaviour already existed and was documented in Webhook authentication, but the API reference did not carry the fields, so clients generated from the spec could not create a BASIC subscription.
  • POST /v2/support-files/upload — new upload endpoint where support_file_code is optional. When provided, RCM skips classification and processes the file synchronously against the provider's support-document catalog (same behaviour as v1), returning 204 No Content. When omitted, RCM persists the file and calls DVS to classify it asynchronously before validation, returning 202 Accepted with a document_id. See Upload support file v2 guide.
  • Webhook events for RCM: DOCUMENT_CLASSIFICATION_COMPLETED, DOCUMENT_CLASSIFICATION_FAILED, DOCUMENT_VALIDATION_COMPLETED, DOCUMENT_VALIDATION_REJECTED. Authenticated per subscription with HMAC-SHA256 (default) or HTTP Basic. See Webhook events and Authentication.
  • Webhook Subscriptions API under /v1/integration/webhooks for managing your own subscriptions (create, pause, resume, reset circuit-breaker, delete).
  • bonus_amount, moderator_fee_amount and discount_amount in the invoice_metadata object of POST /v1/invoices/assign-charges. Three optional numeric amounts reported by the HIS for the invoice. They are stored as received: RCM does not validate them against invoice_amount nor against the charges assigned to the invoice. Additive and backwards compatible — existing integrations need no change.
  • RGA audit events (Brazil / Orizon): CHARGE_AUDIT_ACCEPTED, CHARGE_AUDIT_UPDATED, CHARGE_AUDIT_DELETED, CHARGE_AUDIT_PENDING — one event per audited item, with the payer's decision already derived. Consumed over the integration pull API (/v1/integration/events). Gated by the orizon.rga.classification.enabled feature flag (default off). See Audit events.
  • Webhook event catalog — a new Event catalog page lists every event_type a subscription can receive. Besides the eight stable document and audit events, RCM emits account, charge, invoice, invoice-assignment and settlement-batch events (ACCOUNT_*, CHARGE_*, INVOICE_*, INVOICE_ASSIGNMENT_*, INVOICE_CHARGE_ASSIGNMENT_*, SETTLEMENT_GROUP_*, AUTOMATIC_SETTLEMENT_DELIVERY_ENABLED) that were previously described as "on the roadmap". They are published as preview: emitted today, payload not frozen, enabled per provider. The page also states that an empty subscribed_event_types matches every event type, and lists the six reserved names that are never delivered.

Documented (existing endpoints, newly published)​

These operations were already live in the API — this release documents them for the first time. Nothing about their behaviour changed.

Fixed​

  • DOCUMENT_CLASSIFICATION_* payload keys are camelCase, not snake_case. The classification page documented document_id, support_file_code, error_code…; what RCM actually delivers is documentId, supportFileCode, errorCode…, and optional fields arrive as null instead of being omitted. Verified against the emitting code. The envelope and the validation and audit payloads were, and remain, snake_case. If your receiver was written from the previous page, it never matched a real classification payload.
  • Integration Events: the operational contract is now documented. The pull / ack / stats endpoints now state the visibility timeout (300 s by default), the server-side cap on max_batch_size (50, even though the schema allows 100), that pull requires a JSON body (send {}), that only the positive ack is idempotent — a negative ack consumes a retry attempt — and that pending_count / total_pending include events in IN_PROGRESS. These are configuration defaults and can be tuned per environment. Request fields are snake_case: a camelCase field is silently ignored rather than rejected, so a mis-named event_ids fails validation while the pull appears to work.
  • An event is not read-only after creation. The docs said it was. Resending a charge with the same origin_event_id does not update the header, but PUT /v1/events/origin-events/{originEventId} does.
  • Pre-Attendance document upload limit is 25 MB — a different service and a different limit from the RCM support-file uploads above, which accept 200 MB. Pre-Attendance returns 413; RCM returns 406.
  • Pre-Attendance status machine. DELETE /v1/checkin/appointments/{id} is a soft-delete that does not move the pre-appointment to CANCELLED; the status stays PENDING. CANCELLED and COMPLETED are reached by updating the status with PUT /{id}.
  • HIS inbound identity. (provider, external_appointment_id) is unique only among appointments that are still enabled. After a delete, resending the same external_appointment_id creates a new appointment rather than resurrecting the old one.
  • Error responses, missing 403s and the ERROR value of ai_validation_status added across the Pre-Attendance reference; sort documented as camelCase entity fields.
  • Internal permission names removed from every page and response description — a 403 now describes the condition, not the permission that was missing.
  • Upload size limit and error status corrected in the docs. The RCM support-file upload endpoints accept up to 200 MB (not 25 MB, as previously documented), and an oversized file returns 406 Not Acceptable — RCM never returns 413. The API behaviour did not change; the documentation was wrong. If you calibrated your client on 25 MB or on 413, adjust it.
  • Pre-Attendance: the pre-appointment response schemas were split. One schema was documenting two different payloads. GET/PUT /v1/checkin/appointments/{id}, POST /v1/checkin/appointments, POST /{id}/confirm and the list endpoint return the full record — now PreAppointmentResponse, with all 37 fields including provider, payer, beneficiary, doctor, specialty and charges. The HIS inbound operations return the condensed form, now PreAppointmentSummaryResponse (12 fields). The new PreAppointmentChargeResponse documents the charges entries. Also: charges_count and documents_count were listed on responses that never returned them, and the 409 on confirm was typed with the response schema instead of the error schema.

Deprecated​

  • PUT /v1/accounts/origin-events/{originEventId}/agreement-codes/{agreementCode} — migrate to PUT /v3/accounts/origin-events/change-of-payer. The v1 endpoint still works but emits Deprecation: true and Sunset: Tue, 01 Sep 2026 00:00:00 GMT headers. It will be removed after 1 Sep 2026.
  • PUT /v2/accounts/origin-events/{originEventId}/agreement-codes/{agreementCode} — same Sunset as the v1 route, and the same successor: PUT /v3/accounts/origin-events/change-of-payer. It returns 202 Accepted and emits Deprecation: true, Sunset: Tue, 01 Sep 2026 00:00:00 GMT and a Link header pointing at v3. It will be removed after 1 Sep 2026 — if you are still calling the v2 route, migrate now.

How to subscribe to changes​

This changelog is regenerated on every release. To get notified ahead of time:

  • For breaking changes and deprecations, OSIGU support emails the technical contacts on file for each client_id. Make sure your team's contact email is current.
  • For all changes, watch the rcm-docs repository (or the public mirror at https://rcm-docs.osigu.com) for changes to this page.

If you spot something missing or wrong in the changelog, email support@osigu.com.