Skip to main content

Submit a settlement batch (Radicación)

In the Dominican Republic, providers historically submit groups of claims to a sponsor rather than one-at-a-time. That group is called a settlement batch — radicación in Spanish — and the endpoints live under /v3/settlements/....

If you're integrating outside the Dominican Republic, you almost certainly don't need this flow. Skip to rcm-docs.osigu.com — Osigu's newer product for claim batching uses a different model.

When to reach for this​

  • You're a provider in the Dominican Republic.
  • Your sponsor operates via radicación (most ARS do).
  • You've already completed at least one claim and it's sitting in COMPLETED status.

Concept refresher​

A settlement batch groups one sponsor's completed claims. You can't mix sponsors in a batch. Each batch progresses through:

OPEN → SUBMITTED → ACCEPTED / REJECTED / PARTIALLY_ACCEPTED

Once a batch is OPEN, you attach claims, upload supporting documents, then dispatch it. The sponsor evaluates and responds — sometimes synchronously, sometimes with a webhook days later.

1. Start a batch​

curl -X POST "https://sandbox.osigu.com/v3/settlements" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sponsor_slug": "sponsor-sandbox-do",
    "period": "2026-06"
  }'

Response (201):

{
  "settlement_id": "stl_01HXCK...",
  "status": "OPEN",
  "sponsor_slug": "sponsor-sandbox-do",
  "created_at": "2026-06-25T14:15:00Z"
}

2. List candidate claims​

The system already knows which of your completed claims are pending settlement for this sponsor:

curl "https://sandbox.osigu.com/v3/settlements/stl_01HXCK.../pending-authorizations" \
  -H "Authorization: Bearer $TOKEN"

Response is paginated. Each entry includes the authorization_id, claim_id, total_amount, and dispensation date.

3. Attach claims to the batch​

curl -X POST "https://sandbox.osigu.com/v3/settlements/stl_01HXCK.../authorizations" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "authorization_ids": [
      "auth_01HXA...",
      "auth_01HXB..."
    ]
  }'

Add or remove authorizations any time before dispatch. If you accidentally add one that's already in another batch you'll get 409.

4. Upload supporting documents​

Most sponsors want an invoice, a signed cover sheet, or a receipt aggregate. Upload each as a multipart file:

curl -X POST "https://sandbox.osigu.com/v3/settlements/stl_01HXCK.../documents" \
  -H "Authorization: Bearer $TOKEN" \
  -F "file=@./invoice.pdf" \
  -F "document_type=INVOICE"

Repeat for each required document_type. To find out which document types the sponsor requires for this batch, check the sponsor's onboarding notes — this varies by country and by ARS.

5. Dispatch the batch​

curl -X POST "https://sandbox.osigu.com/v3/settlements/stl_01HXCK.../dispatch" \
  -H "Authorization: Bearer $TOKEN"

Response (200):

{
  "settlement_id": "stl_01HXCK...",
  "status": "SUBMITTED",
  "submitted_at": "2026-06-30T09:22:11Z"
}

The batch is now in the sponsor's hands. Claims in the batch move from COMPLETED to SETTLED.

6. Track the outcome​

Poll getSettlement — or listen for the settlement.* webhooks:

  • settlement.paid — the sponsor accepted the batch and the payment cycle has started.
  • settlement.rejected — the sponsor rejected the batch. Response includes the reason and which claims are affected. You'll typically fix the offending claims and re-batch.
  • settlement.partially_accepted — some claims accepted, others rejected. Response lists per-claim outcomes.

7. Void an in-flight batch​

Before you dispatch — while it's still OPEN — you can void the batch:

curl -X POST "https://sandbox.osigu.com/v3/settlements/stl_01HXCK.../void" \
  -H "Authorization: Bearer $TOKEN"

Claims previously attached move back to COMPLETED and are available for another batch.