Duesly (payments)

Duesly collects recurring payments over WhatsApp. These endpoints are for when the customer list already lives somewhere else, such as your billing system, a spreadsheet pipeline or a POS, and you want Duesly to do the chasing without anyone retyping it.

Duesly is part of Campaigns, so it uses the campaign scopes rather than its own.

The app has to be installed #

Every endpoint here answers 412 when the workspace hasn't installed Duesly:

{
  "error": {
    "code": "failed_precondition",
    "message": "The Duesly app is not installed in this workspace.",
    "details": { "reason": "not_found", "docs": "https://docs.amomic.in/apps/overview" },
    "request_id": "req_01JRBC2D5F8H1K4M7P0R3T6V9X",
    "correlation_id": "cor_01JRBC2D5F8H1K4M7P0R3T6V9X"
  }
}

That is deliberately not a 404: a 404 on a workspace that hasn't installed the app would look the same as a typo in the URL. Install it from Campaigns → Apps; see Apps.

Reminders, follow-ups, templates and how you get paid are set in the console, not here. The API adds and reads the data; the app owns the behaviour.

Adding a subscriber #

curl -X POST https://services.amomic.in/api/v1/apps/duesly/subscribers \
  -H "Authorization: Bearer $AMOMIC_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: sub-VH-CUST-40718" \
  -d '{
    "name": "Rohit Deshpande",
    "phone": "+919823016745",
    "email": "rohit.deshpande@example.in",
    "plan_name": "AC annual maintenance (2 units)",
    "amount": 749.5,
    "cycle_unit": "monthly",
    "due_day": 5,
    "start_date": "2026-11-05"
  }'

201 Created, with the subscriber:

{
  "subscriber_id": "sub_01JRBC6G9J2L5N8Q1S4U7W0Y3A",
  "tenant_id": "org_veloria_home",
  "contact_id": "cnt_01JRBC6H0K3M6P9R2T5V8X1Z4B",
  "contact_pending": false,
  "name": "Rohit Deshpande",
  "phone": "+919823016745",
  "email": "rohit.deshpande@example.in",
  "plan_name": "AC annual maintenance (2 units)",
  "amount": 749.5,
  "currency": "INR",
  "cycle_unit": "monthly",
  "cycle_days": null,
  "due_day": 5,
  "start_date": "2026-11-05",
  "status": "active",
  "notes": null,
  "tags": [],
  "next_due_date": "2026-11-05",
  "last_paid_at": null,
  "collected_total": 0,
  "outstanding_total": 1499.0,
  "dues_paid": 0,
  "dues_declined": 0,
  "version": 2,
  "created_at": "2026-10-14T06:21:48.093517+00:00",
  "updated_at": "2026-10-14T06:21:48.611204+00:00"
}

Two things happen beyond the write:

• They become a contact, so they appear in Contacts and every conversation with them sits in one place.
• Their next two payments are raised immediately, so next_due_date and outstanding_total are already filled in and a GET /dues right after this returns them, rather than waiting for the next scheduled run. payment.due_created fires for each.

The phone number is stored in E.164. status is active, paused or cancelled; pausing and cancelling a subscriber happen in the console.

If the contact can't be linked, because the directory couldn't be reached or the details belong to two different existing contacts, the subscriber is still created, with contact_id: null and contact_pending: true. Reminders still go out, and the console offers a retry. A directory blip must not stop a business taking payments.

POST /subscribers honours Idempotency-Key. Set it to your own customer id so a re-run of your sync is safe. See Idempotency.

Listing subscribers #

Newest first. Returns {"items": [subscriber, …], "next_cursor": "…"}, each item shaped like the create response. There are no filters. See Pagination.

Reading what is owed #

"Today" is today in your workspace's time zone.

curl -G https://services.amomic.in/api/v1/apps/duesly/dues \
  -H "Authorization: Bearer $AMOMIC_API_KEY" \
  --data-urlencode "scope=overdue" \
  --data-urlencode "limit=100"

{
  "items": [
    {
      "due_id": "due_4c81e07b2f9a63d5c18e47b20a",
      "tenant_id": "org_veloria_home",
      "subscriber_id": "sub_01JQ7T2V5X8A1C4E7G0J3L6N9Q",
      "subscriber_name": "Sneha Pillai",
      "phone": "+919946102385",
      "contact_id": "cnt_01JQ7T2W6Y9B2D5F8H1K4M7P0R",
      "period_label": "October 2026",
      "amount": 1249.0,
      "currency": "INR",
      "due_date": "2026-10-05",
      "status": "followup_1",
      "collection_mode": "manual_upi",
      "payment_link": null,
      "payment_link_id": null,
      "payment_reference": null,
      "paid_at": null,
      "paid_amount": null,
      "marked_by": null,
      "marked_by_name": null,
      "reminders_sent": 2,
      "last_reminder_at": "2026-10-06T04:30:12.507311+00:00",
      "next_action_at": "2026-10-07T04:30:00+00:00",
      "campaign_id": "cmp_01JRAZ1B4D7F0H3K6M9P2R5T8V",
      "failure_reason": null,
      "version": 3,
      "created_at": "2026-10-01T00:30:04.118205+00:00",
      "updated_at": "2026-10-06T04:30:12.507311+00:00"
    }
  ],
  "next_cursor": null
}

The statuses are a ladder, and it is finite:

A payment gets one reminder and at most two follow-ups. See the reminder ladder: the limit is fixed and no API call raises it.

Recording a payment #

For money collected outside the payment link: cash, a bank transfer, UPI to your own account, a cheque. With a payment gateway connected, link payments settle themselves and you don't need this.

curl -X POST https://services.amomic.in/api/v1/apps/duesly/dues/due_4c81e07b2f9a63d5c18e47b20a/paid \
  -H "Authorization: Bearer $AMOMIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "expected_version": 3,
    "amount": 1249,
    "reference": "UPI 428617093512",
    "paid_at": "2026-10-14T10:42:00+05:30"
  }'

200 OK, with the due as it now stands: status paid, paid_amount, paid_at, payment_reference, and version one higher. The subscriber's totals are updated, the chase stops, and payment.paid fires. If you've set up a receipt in Duesly, the customer gets it.

Recording a payment also tries to cancel the due's live payment link, so nobody pays twice. That cancel is best-effort: if it fails, the payment is still recorded.

Idempotent by state, not by key #

This endpoint ignores Idempotency-Key. A due can only be marked paid while it's open, so a retried call can't rewrite a settled payment:

The version is checked first. So a retry of a call that already worked usually gets the 409, because marking it paid moved the version on. In both cases, read the due again: if it's paid, your payment, or someone else's, is already recorded.

Failures #

Events #

The reason to integrate here rather than poll:

payment.due_created fires the moment a payment is raised, so your own ledger can mirror the invoice without polling for it.

See Webhooks and Verifying signatures.

A worked integration #

The shape that works for most billing systems: