Rental Agreement E-Stamping for Property Managers and Brokerages

Key takeaways

• Treat agreements as a pipeline with named stages, from "renewal due" to "document delivered". Every stage has an owner, an API call, a failure mode and a metric.
• Agreements for residential tenancies commonly run for eleven months in India, so a portfolio of N flats generates roughly N divided by eleven renewals a month. Use that to size your workload, your wallet and your team.
• Never hardcode duty, article numbers or state rules. Ask the lookup and calculation endpoints every time, and have counsel sign off the process per state before you switch a state on.
• Stamp after the terms are final and the parties are verified. A name error on an issued stamp is expensive to fix, while a PAN or bank check before ordering costs a few rupees.
• Send an Idempotency-Key on order creation and payment intents, and use your own externalOrderId as a unique key in your database, so a retried batch never creates a second order.
• Money has three layers: StampMitra's per-order API fee, the state's procurement fee and the statutory stamp duty. The last two are not discounted and vary by state, so quote them to the client from the API, never from a table you keep.
• Reconcile daily: orders created, payments confirmed, documents delivered, wallet movement and usage totals should tell one story.
• Registration is a separate legal step from stamping. Your process must not imply that stamping alone completes a tenancy.

Who this page is for

Four kinds of operators run into this workload.

Property managers look after flats for owners and handle agreements as a service. Their volume is predictable because renewals follow a calendar, and their risk is that a lapsed agreement leaves an owner exposed.

Brokerages create new agreements as part of closing a rental. Their volume follows the market and their risk is delay: a tenant who cannot get a stamped agreement on the day may go elsewhere.

Co-living and managed-stay operators create many short agreements for individual rooms and beds. Their risk is volume, with many parties per property and frequent turnover.

Law offices and secretarial firms prepare agreements for many landlord clients. Their risk is accuracy and traceability, because each document may be examined later.

All four need the same four things: speed, accuracy, a record, and a way to charge the cost to the right party.

The renewal factory: sizing the workload

The easiest way to run this is to think about the calendar. If your standard agreement term is eleven months, a portfolio of 1,100 flats produces about 100 renewals a month, a portfolio of 11,000 produces about 1,000, and 110,000 produces about 10,000. New lettings come on top of that, as do mid-term changes and early terminations.

Two things follow. First, renewals are predictable, so you can pre-stage them: start the process some weeks before expiry, verify parties early and have the draft ready for signature well before the due date. Second, peaks are predictable too. If many agreements start on the first of the month, expect a spike a few days earlier. Plan wallet funds, worker capacity and reviewer cover for that spike rather than discovering it on the day.

The numbers in the table below are the sizing assumption used in the cost section later. Replace them with your own.

What changes when you do hundreds a month

At volume, five things change that a single-agreement product never notices.

The first is that exceptions dominate. If one in twenty agreements has a data problem, a one-off app sees it rarely, while a manager with 1,000 renewals sees fifty a month. Your process needs a proper exception queue and an owner.

The second is that identity checks become a bulk job. Owners are repeat parties, so you verify them once and reuse the result for every renewal on their properties, instead of re-checking each time. Tenants are new each cycle and need a check per agreement.

The third is that cost visibility matters. At ten thousand orders a month, a small per-order saving or a missed pass-through is real money.

The fourth is that timing becomes a service level. Delivering a stamped document two days late is a missed commitment, so the pipeline needs clocks.

The fifth is that audit becomes routine. Clients, auditors and sometimes courts ask for the record of a particular agreement. You need to produce it in minutes.

The pipeline, stage by stage

A useful pipeline has stages that are short, observable and owned. The table sets out a reasonable set, and the API call that drives each.

Keep the stage as a field on the agreement record, and log every transition with a timestamp. Those timestamps drive the clocks and the metrics.

The workflow, step by step

1. Pre-stage renewals. A scheduled job selects agreements expiring in the coming weeks and creates pipeline records. Decision: records exist for every expiry, so none is missed.
2. Confirm terms with the parties. Rent, deposit, term, start date and property address. Decision: terms final or not. Do not proceed to a quote on drafts that are still being negotiated.
3. Verify the owner once. POST /v1/verify/pan with the owner's PAN and legal name, and, if the owner will receive rent or deposit refunds by transfer, POST /v1/verify/bank-account with the account and name. Store the results against the owner, not the agreement. Decision: owner status valid, review, or blocked.
4. Verify the tenant for this agreement. The same PAN check, and a bank check if you will refund the deposit to an account you collect now. Decision: as for the owner.
5. Resolve state, instrument and article. From the lookup endpoints, not from your own table. Decision: the article is selected by a rule your counsel approved for the state, or by a person.
6. Calculate. POST /v1/estamp/duty/calculate with stateCode, articleCode and stampDutyAmount, plus district or SRO values where the state needs them. Decision: quote shown to the payer; if inputs change, calculate again.
7. Create the order and attach parties. POST /v1/orders with externalOrderId, externalCustomerId, serviceCode and details, with an Idempotency-Key; then POST /v1/estamp/orders/:orderId/parties. Decision: order id recorded before anything else happens.
8. Pay. POST /v1/payments/intents with the externalOrderId, amountMinor, currency and paymentConnectionId. Decision: wait for the confirmed state; never mark paid from the browser.
9. Track. Poll GET /v1/orders/:id/status with backoff, or use order events where your account receives them. Decision: completed, in progress or failed.
10. Fetch and store the document. GET /v1/orders/:id/documents, then the download endpoint, and store the bytes. Decision: the stored copy is the record, never the temporary URL.
11. Deliver and close the stage. Send to the parties and the client. Record who received what and when.

Sample request and response: creating the order

The order step is where your own references meet StampMitra's. This is the documented request for the generic order endpoint with an e-Stamp service code, followed by the documented response:

curl -X POST "https://api-b2b.stampmitra.in/v1/orders" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Idempotency-Key: order-RENT-2026-000481-v1" \
  -H "Content-Type: application/json" \
  -d '{
    "externalOrderId": "ord_ext_123",
    "externalCustomerId": "cust_ext_456",
    "serviceCode": "estamp.instrument.rent_agreement",
    "details": { "state": "MH", "stampValue": 500, "note": "Shape not finalized - illustrative only" }
  }'

{
  "externalOrderId": "ord_ext_123",
  "createdAt": "2026-10-15T09:41:07.000Z",
  "serviceCode": "estamp.instrument.rent_agreement"
}

The details object is the part that deserves caution: the docs say its shape for e-Stamp is not finalised, so read the schema endpoint, keep the mapping in one place and re-check it before each release. The sample above is illustrative, as the note inside it says.

The Node function below shows a renewal batch that is safe to restart. It uses the agreement reference for the idempotency key, skips agreements that already have an order, and stops on a wallet error rather than hammering the endpoint.

const BASE = "https://api-b2b.stampmitra.in";
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function createOrder(agreement) {
  const res = await fetch(`${BASE}/v1/orders`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.STAMPMITRA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": `order-${agreement.ref}-v1`,
    },
    body: JSON.stringify({
      externalOrderId: agreement.ref,
      externalCustomerId: agreement.ownerId,
      serviceCode: agreement.serviceCode,
      details: agreement.details,
    }),
  });
  return { status: res.status, body: await res.json() };
}

export async function runRenewalBatch(agreements, store) {
  for (const a of agreements) {
    if (await store.hasOrder(a.ref)) continue;
    let out = await createOrder(a);
    for (let attempt = 0; attempt < 3 && (out.status === 429 || out.status === 502); attempt++) {
      await sleep(1000 * 2 ** attempt + Math.random() * 400);
      out = await createOrder(a);
    }
    if (out.status === 402) throw new Error("WALLET_LOW: stop the batch and alert finance");
    await store.recordOrderAttempt(a.ref, out);
    await sleep(1100);
  }
}

Decision table: valid, mismatch, inactive, not found

This table covers the people and the order, since both can fail.

One platform, many states: how to switch states on

Stamp duty and the related rules are set at state level, which means your pipeline must be able to behave differently per state without branching in code. The approach that works is a state profile, kept as data, with a switch per state.

For each state you serve, hold a profile that records: whether the state is in the lookup endpoints for your entitlement, which articles your counsel has approved for each agreement type, the extra inputs the calculation needs (district, SRO value, delivery options), the notice text you show about registration and reporting, and whether the state is switched on. Only switch a state on after counsel has reviewed the notice and the article rule, and after a sandbox run for that state.

Do not copy rates, thresholds or deadlines into the profile. Where a figure matters, the API returns it or the state authority publishes it, and your profile points to that source. The profile controls the process, never the numbers.

Money: what the payer is charged

An e-stamp order has three cost layers, and the client needs to see them separately.

The first is the statutory stamp duty, which the state sets. The second is the state-wise procurement fee, which StampMitra shares when production access is approved and quotes in full before you place an order. The third is StampMitra's e-Stamp API fee per order, which depends on your plan. Neither duty nor the procurement fee is discounted by plan. The pricing page lists the API fee for every plan.

The API response for the calculation is the authority for what to charge for duty and service charges, and the amount is not to be recalculated or overridden client-side. If you add your own service fee, show it as a separate line item. Keep your fee out of the amount you pass to the payment intent unless your product collects it that way by design, and make sure the invoice you issue reflects the split.

Payment goes through a payment intent for the order, and verification and order calls draw on your fulfilment wallet. StampMitra's invoices are GST invoices, and plan and usage charges carry GST at 18 percent. Set wallet alerts well above the balance a day's peak will need, and fund before month-end spikes.

Bulk renewals: batching, pacing and payment

Process renewals in batches by due date, with a worker pool kept inside your plan's rate limit (the documented error example is 60 requests per 60 seconds; read your own limit from the dashboard and the pricing page). Create orders first, then payment intents, then poll, in separate stages with their own queues, so a slow stage does not block the others. Retry only 429 and 502 with backoff. Treat 402 as a stop and alert finance, because every later call will fail the same way.

Pay in a way that matches how you charge clients. If the client prefunds you, pay each intent as the order is created. If you invoice afterwards, make sure the wallet and the payment connection can absorb the batch. Keep one payment intent per order, and read the intent state before creating another after any timeout, to avoid paying twice.

Reconciliation: one story from four sources

Run a daily reconciliation and a monthly one. The daily check compares four things: orders created in your system against orders known to the API, payments confirmed against orders awaiting payment, documents stored against orders completed, and wallet movement against the sum of what you expect to have spent. The monthly check ties usage to invoices and to what you billed clients.

On the StampMitra side, GET /v1/usage/summary returns usage totals for the current billing period with calls by service and by day, and GET /v1/logs returns request logs with filters for service and status, paginated by a cursor. Use them as an independent view of your own records. Discrepancies are usually one of three things: an order created but never paid, a payment taken without an order you know about because a retry created a duplicate, or a document fetched but never stored. Each has a fix, and the earlier you find it the cheaper it is.

import os
import requests

BASE = "https://api-b2b.stampmitra.in"
HEADERS = {"Authorization": f"Bearer {os.environ['STAMPMITRA_API_KEY']}"}

def api_usage_by_service():
    r = requests.get(f"{BASE}/v1/usage/summary", headers=HEADERS, timeout=20)
    r.raise_for_status()
    return r.json()["callsByService"]

def reconcile(expected_counts: dict[str, int]) -> list[str]:
    actual = api_usage_by_service()
    problems = []
    for service, expected in expected_counts.items():
        got = actual.get(service, 0)
        if got != expected:
            problems.append(f"{service}: ledger says {expected}, API says {got}")
    return problems

Exceptions you will meet

Five exceptions account for most of the work in the exception queue.

A party name is wrong after issuance. The stamp already exists. Do not quietly edit the agreement. Decide with counsel whether a corrected order is needed, create it as a new order linked to the old one, and keep both in the record.

The wrong article was selected. Same approach, plus a review of why the rule picked it. Fix the rule for the state profile.

The tenant withdraws before payment. An unpaid order simply stays unpaid; record the reason and close the pipeline record. What happens after payment, including refunds, is governed by the platform's billing and refund policies and the order's status; read the billing, API credits and refund policy and ask support rather than assuming.

A duplicate order exists. Usually a retry without an idempotency key. Find it by externalOrderId and your own uniqueness check, and contact support with the requestId values before paying a second intent.

The certificate is not ready. Poll with backoff, check the status response, and contact support with the requestId if the order is stuck beyond the time you expect.

Five scenarios from a property manager's desk

These are hypothetical cases.

The renewal month

A manager with about a thousand renewals in a month pre-stages them six weeks out. The owner PAN and bank results are already stored from last year's cycle, so only tenant checks run. Quotes are calculated as each agreement is finalised. By the twentieth most are ordered and paid; the rest are in the exception queue with reasons.

The owner with a different name on the PAN

An owner who inherited a flat shows a legal name on PAN that differs from the name on the previous agreement. The review queue holds the agreement until the owner supplies the document that explains the change. The new agreement uses the PAN's legal name, and the owner record is updated with the reviewer's note.

The wallet that ran low

On the last day of the month a batch hits a 402. The worker stops, finance is alerted, the wallet is funded, and the batch resumes from where it stopped. Because order creation uses idempotency keys and the batch skips agreements that already have orders, nothing is duplicated.

The new state

The brokerage wants to start serving a state it has not covered. The state appears in the lookups; counsel approves the article rule and the registration notice; a sandbox run succeeds; the state is switched on for a pilot of a few agreements before general use.

The late certificate

An order stays in progress longer than expected. The pipeline clock flags it, an analyst checks status and logs, and support is contacted with the requestId. The tenant is told the document is delayed and given a new expected time, instead of silence.

Review rules a property operator can copy

These are suggestions for your policy to adapt.

• Verify before stamping. No order until owner and tenant checks have cleared or been reviewed.
• Legal names only. The agreement carries the name as verified on PAN, with any alias noted separately.
• No order on drafts. Terms must be final and acknowledged by both sides.
• Counsel-approved articles per state. A person selects the article where the rule is not defined.
• Second approver for corrected orders and for any order whose value exceeds a limit you set.
• Wallet floor. An alert at a balance that covers a day's peak, and a hard stop for batches below a lower floor.
• No manual retries without a key. Any manual re-submission uses the same idempotency key.
• Registration notice recorded. The user sees and acknowledges the notice for their state.

Operating model

Organise the work in three queues. The pipeline queue holds agreements waiting on parties or on payment; its owners are coordinators who chase signatures and funds. The review queue holds identity mismatches and article questions; its owners are analysts with a named senior reviewer and a path to counsel. The platform queue holds failed calls, wallet alerts and stuck orders; its owner is engineering or the on-call operator.

Give each stage a clock and show the oldest item per queue on a shared screen. Suggested starting targets are same business day for review items near a due date and a defined time from payment to delivery that you measure and tune. Staff for the monthly peak, not the average.

What to store and for how long

Per agreement store your reference, the order id, the state, the article, the inputs to calculation and the response as received, the parties as submitted, the verification referenceId values, the payment reference, every status change with a timestamp, the document files with checksums, and who delivered what to whom. Store the certificate bytes in your own encrypted, access-controlled storage and serve them through your authenticated endpoint. Never rely on the temporary download URL.

Retention periods for tenancy records depend on the document, your contracts with clients and owners, tax and accounting rules, and data-protection law for the individuals involved. We cannot give you the figures. Take the question to counsel, write the answer into a schedule, and automate it. StampMitra's own data handling is in its retention and deletion schedule and data processing addendum.

What it costs: three portfolio sizes

The StampMitra API fee is ₹5 per order on pay as you go, and lower on Growth and Scale; the verification calls are ₹5 each for PAN and ₹4 for the bank account. All figures exclude GST at 18 percent. They also exclude two things you must add: the statutory stamp duty and the state procurement fee, which are the same on every plan and are quoted to you before an order. Duty-calculation calls are metered against your wallet; confirm with support how they are priced on your plan before you model quote volume, because the tables below do not include them.

The per-file view first. One agreement with a PAN check on each party, a bank check on the owner and one order, and then the API fee alone for an order:

Now the monthly models, using the three portfolio sizes from earlier and counting one order a month for each expected renewal. Owner checks are reused across years, but to keep the model simple we count them every time, which overstates cost. At 100 agreements a month: 200 PAN checks, 100 bank checks and 100 orders.

At 1,000 agreements a month: 2,000 PAN checks, 1,000 bank checks and 1,000 orders.

At 10,000 agreements a month: 20,000 PAN checks, 10,000 bank checks and 10,000 orders.

Reading the tables: at 100 agreements a month pay as you go is cheapest because the plan fees outweigh the lower rates; at 1,000 the three plans come out within a few thousand rupees of each other, with Growth cheapest in this model; at 10,000 Scale is cheapest, and the spend is above the point at which StampMitra suggests an enterprise arrangement, which is a conversation for the contact page. The tables assume GST applies to plan fees as well; confirm on an invoice. These totals are small next to the stamp duty and procurement fees on the same orders, so the real decision between plans is rarely about the API fee alone. Usage is recorded after a successful response, so calls that fail with an error are not charged, although valid: false is a successful answer and is charged.

Rollout: sandbox, pilot, production

Sandbox. Build the pipeline against sandbox keys, where responses are sample data and the wallet is never debited. Use the services list, schema and lookup endpoints to discover the real shapes that the e-Stamp docs mark as placeholders. The sandbox responder gives a valid result for the PAN SNDBX0000A and an invalid one for SNDBX9999F; other inputs give stable but arbitrary outcomes, so do not assert on them. Confirm the current test values in the dashboard. Test restart safety, idempotency, wallet-stop behaviour, the state-profile switch and every row of the decision table.

Pilot. Request production access, which needs your organisation's KYC approval and the per-product application, and during which you receive the state-wise procurement fees. Run a small number of real agreements in one state end to end with counsel watching, and reconcile every one by hand.

Production. Widen by state and by client. Run daily reconciliation from day one. Alert on wallet balance and on any stage clock that passes its target. The sandbox versus production keys guide covers scopes, keys and the IP allowlist.

Metrics worth watching

• Renewals due, renewals pre-staged, and renewals delivered before expiry. The last is the one your clients care about.
• Time per stage and end to end, with the slowest ten percent examined weekly.
• Exception-queue size by reason, and the age of the oldest item.
• Corrected orders as a share of all orders. This tracks data quality at intake.
• Duplicate orders detected, which should be zero.
• Wallet balance against forecast, and the number of 402 events.
• Reconciliation differences per day, and how long each took to resolve.
• Cost per delivered agreement, including all three cost layers.

Mistakes that hurt operators

• Stamping before terms are final. Duty is paid up front; changes mean new orders.
• Re-verifying owners every renewal. Verify once, reuse, and re-check on events.
• Hardcoding duty or article tables. They change and differ by state.
• No idempotency keys. A restarted batch creates duplicate orders.
• Saving the download URL as the record. It expires; save the bytes.
• Running one reconciliation a month. Problems are cheapest on the day they appear.
• Promising clients that stamping completes the tenancy. Registration and reporting are separate and state-specific.
• Mixing your fee into the duty amount. Keep lines separate on the quote and the invoice.

Related APIs and guides

The endpoints used here are in the e-Stamp API documentation: duty calculation, orders, parties, payment and documents, together with the PAN and bank account verification endpoints. For more reading, see the rental agreements for proptech use case, the e-stamp order flow guide, bank account verification before payout, the verification for legal and compliance teams page, the errors guide and the webhooks page for order events. All industry pages are on the solutions page, and current rates are on the pricing page.

API reference at a glance

{
  "externalOrderId": "ord_ext_123",
  "createdAt": "2026-10-15T09:41:07.000Z",
  "serviceCode": "estamp.instrument.rent_agreement"
}

{
  "referenceId": "SMV-20260927-8F42K7",
  "pan": "ABCDE1234F",
  "type": "Individual",
  "valid": true,
  "registeredName": "RAHUL KUMAR",
  "fatherName": "SURESH KUMAR",
  "panStatus": "VALID",
  "panStatusCode": "E",
  "panStatusDescription": "Existing and valid PAN",
  "nameMatchResult": "MATCH",
  "nameMatchScore": "100",
  "aadhaarSeedingStatus": "y",
  "aadhaarSeedingStatusDescription": "Aadhaar linked",
  "lastUpdatedAt": "2023-04-01",
  "message": "PAN is Valid"
}

Frequently asked questions