Skip to main content
A SIP (systematic investment plan) invests a fixed amount in a scheme on a recurring schedule. You register it once; every installment after that is debited automatically on its due date. You never create or pay an installment yourself.
1

Register the SIP

POST /api/orders/v1/ with order_type: "SIP". Validated and persisted synchronously, then registered with the exchange in the background. Returns 202.
2

Investor authorises it

Once the SIP is ACCEPTED, the order carries a payment_link — an authorisation page the investor opens to approve the plan.
3

Installments run on their own

The SIP becomes REGISTERED and each installment is debited on its due date against the investor’s mandate. Progress shows up on the order and under GET /api/orders/v1/:id/installments.

Prerequisites

  • The investor is status: REGISTERED (see Create an investor).
  • An investment account exists for the investor.
  • A REGISTERED mandate whose limit covers the installment amount — it is what funds each debit.
  • The scheme has sip_allowed: true. Check its sip_frequencies, sip_dates and min_sip via schemes first.

Register the SIP

Response 202:

Fields

amount is the per-installment amount. Fields not listed here behave as in Create a Purchase Order.

Step-up (optional)

Validation

Rejected synchronously before the 202:
Send an Idempotency-Key (UUID), exactly as for purchase orders.

Authorise the SIP

Once the order reaches ACCEPTED, GET /api/orders/v1/:id returns a payment_link. Hand it to the investor to approve the plan. It is an authorisation page, not a payment page — no money moves at this step, and you do not call POST /api/payments/v1/ for a SIP. The link can take a moment to appear after the order is accepted; poll the order, or wait for the order.accepted webhook.

SIP lifecycle

Unlike a lumpsum order, a SIP is never ALLOTTED itself: each installment is allotted units individually.

Track a SIP

GET /api/orders/v1/:id returns the schedule and live progress in a systematic block:
The progress fields (installments_paid onwards) are refreshed periodically, so they can trail a debit by a few hours.

Installments

Read-only history of the installments collected so far, oldest first. There is no endpoint to create one — they are debited automatically on their due dates.
The next scheduled installment is systematic.next_due_date on the order, not a row here. The list is empty for any order type other than SIP. GET /api/orders/v1/:id/events returns the status trail ({ from, to, at, remark }).

Manage a live SIP

Pause a SIP

Skips no_of_installments installments starting from from. Allowed only while the SIP is REGISTERED or PAUSED — otherwise 409 INVALID_STATE. The request is acknowledged immediately, but the order’s status changes asynchronously once the pause is confirmed.

Modify a SIP

Only the installment amount and contact/administrative fields (folio_no, euin, sub_broker_code, sub_broker_arn, primary_holder_email, primary_holder_mobile, remarks) can change. Schedule fields — frequency, day, start date, installments — cannot; cancel and register a new SIP instead.

Cancel a SIP

Allowed from PENDING, SUBMITTED, ACCEPTED, REGISTERED or PAUSED — otherwise 409 INVALID_STATE. Installments already collected are unaffected; units already allotted stay with the investor.

Webhooks

Subscribe to order.* (see Webhooks): Payloads are the usual thin { order_id, status, provider_remark } — GET the order for the full record.