canonical: https://jentic.com/apis/instamojo.com/instamojo

# Instamojo Payments API

Jentic publishes the only available OpenAPI specification for Instamojo Payments API, keeping it validated and agent-ready. The Instamojo v2 Payments API lets Indian merchants create payment requests, query payment status, and process refunds, with a separate /oauth2/token exchange to obtain a bearer access token. The surface area is small and focused - five endpoints covering the request, lookup, and refund lifecycle - which makes it well suited to embedded checkout flows on Indian e-commerce sites and marketplaces. A test base URL at test.instamojo.com mirrors production for safe development.

## For AI agents

Create Instamojo payment requests, look up payment status, and issue refunds for Indian merchants using the v2 Payments API.

## Scope

Does not handle subscription billing, payouts to vendors, or international card processing - use for one-time INR payment requests, status, and refunds only.

## Capabilities

- Create a payment request with amount, purpose, and buyer details via POST /v2/payment_requests
- Look up the status of a payment request including its constituent payments via GET /v2/payment_requests/{id}
- Retrieve a specific payment under a payment request to confirm settlement
- Issue a refund against a payment via POST /v2/resolutions
- Exchange client credentials for an access token via POST /oauth2/token

## Use cases

### Embedded Checkout for Indian E-Commerce

Generate a hosted Instamojo payment link by calling POST /v2/payment_requests with the order amount, buyer email, and a redirect URL, then surface the returned long URL to the customer. After the customer completes the payment, GET /v2/payment_requests/{id} confirms the status before the order is fulfilled. The full flow can be wired in a few hours since only two endpoints are involved.

Example prompt: Create a payment request for INR 1,499 with a redirect URL, return the long URL to the customer, and poll GET /v2/payment_requests/{id} until status is Completed.

### Refund Workflow for Customer Support

When a support agent approves a refund, automate the resolution by POSTing to /v2/resolutions with the original payment id, refund type, and amount. The endpoint creates an Instamojo resolution that triggers the refund settlement, replacing manual dashboard work and giving the customer a tracked refund identifier.

Example prompt: POST /v2/resolutions with the payment id and amount to refund, then surface the resolution id back to the support tool.

### AI Agent Payment Operator via Jentic

An AI agent that handles order creation can call Instamojo through Jentic to mint a payment link, then check status and issue refunds without holding the bearer token. Jentic manages the OAuth client credentials and exposes each operation by intent, so the agent can complete the checkout-to-refund lifecycle from natural-language tasks.

Example prompt: Through Jentic, call instamojo_create_payment_request with the order amount and buyer email, return the long URL, and call instamojo_get_payment_request to verify status before fulfilment.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v2/payment_requests | Create a payment request |
| GET | /v2/payment_requests/{id} | Get a payment request and its payments |
| GET | /v2/payment_requests/{payment_request_id}/payments/{payment_id} | Get a specific payment |
| POST | /v2/resolutions | Create a refund resolution |
| POST | /oauth2/token | Exchange client credentials for a bearer token |

## Key resources

- **Payment Requests** — Create and look up payment requests representing a charge to a buyer.
- **Payments** — Retrieve individual payment records under a payment request.
- **Refunds (Resolutions)** — Issue refunds via the resolutions endpoint.
- **Authentication** — Exchange client credentials for an access token.

## Why Jentic

- **Setup:** Wiring the Instamojo Payments API by hand means minting a bearer token from /oauth2/token, choosing between the production api.instamojo.com host and the test host, and mapping its payment-request endpoints yourself. Through Jentic you install once, import the Instamojo Payments API from the API Directory, store the client credentials once, and your agent calls it.
- **Permission scoping:** Instamojo puts the payment request id in the URL path (/v2/payment_requests/{id}), so a rule can pin your agent to reading the status of one payment request. You choose the operations it may call, so creating payment requests or filing refund resolutions are not included unless you add them.
- **Credential handling:** Your Instamojo OAuth client credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time, and the minted bearer token never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an Instamojo payment request' or 'refund an Instamojo payment', and Jentic returns the matching v2 operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Cashfree API** — Cashfree provides Indian payment processing with broader payout and split-settlement features.
- **PayPal Payments API** — PayPal Payments handles cross-border card and wallet checkout outside India.
- **Stripe API** — Stripe complements Instamojo when a merchant sells both inside and outside India.

## FAQ

### Why is there no official OpenAPI spec for Instamojo Payments API?

Instamojo does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Instamojo Payments API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Instamojo Payments API use?

The API uses bearer authentication. You exchange client credentials at POST /oauth2/token for an access token, then send it as Authorization: Bearer <token> on subsequent calls. Through Jentic, the client credentials are held in your encrypted Jentic One instance and the bearer token is injected at execution time.

### Can I issue refunds with the Instamojo Payments API?

Yes. POST /v2/resolutions creates a refund resolution against a specific payment id. You supply the payment id, refund type, and amount, and the response includes a resolution id you can persist for reconciliation.

### What are the rate limits for the Instamojo Payments API?

The OpenAPI specification does not encode explicit rate limits. The endpoints are transactional rather than bulk, so design integrations around per-order calls; back off on 429 responses and avoid polling /v2/payment_requests/{id} more often than every few seconds.

### How do I create a payment link through Jentic?

Install with pip install jentic, then run the search-load-execute flow with the query 'create an Instamojo payment request'. Jentic returns the operation bound to POST /v2/payment_requests; the agent supplies amount, purpose, buyer name, and redirect URL, and receives a long URL to share with the customer.

### Is there a sandbox base URL?

Yes. The OpenAPI spec lists https://test.instamojo.com alongside the production base URL https://api.instamojo.com. Point the bearer token issued for the test environment at the test base URL during development.

### Can I limit what my agent is allowed to do with the Instamojo Payments API?

Yes. Because you run Jentic One yourself, your own rules decide which Instamojo operations your agent may call, so you can allow only reading a payment request's status via GET /v2/payment_requests/{id} while withholding creating requests via POST /v2/payment_requests or filing refunds via POST /v2/resolutions. Instamojo puts the payment request id in the URL path, so a rule can pin the agent to a single payment request rather than the whole account. The OAuth client credentials stay in your self-hosted instance and the minted bearer token is injected only for the operations you have permitted.