Stores
Shopify, WooCommerce, Medusa
Orders in; stock, prices and dispatch back out.
Custom integrations
Every app, wired to your books. Custom integrations for ERPNext and Tally
We write the connection ourselves: REST APIs, GraphQL and webhooks between ERPNext or Tally and your store, payments, bank, WhatsApp and CRM.
Each event is checked, retried if it fails, logged, and posted once.
Trace one event
From the app to your books
When
it lands in
Shopify tells usComplete
Shopify sends orders/paid the moment it happens
Checked and storedComplete
HMAC signature checked against your app's secret. Stored with its own id, so a repeat delivery does nothing.
MappedComplete
Order #1042 to the order's reference
Line SKU KT-M to Item code
Ship-to state to GST place of supplyWritten to ERPNext: Sales OrderComplete
POST /api/resource, as an API user with only the roles it needs
Answered back, and loggedComplete
Stock and the tracking number go back through Shopify's Admin API. Every call and answer is logged, searchable by order number.
Sample event and field names; the method is the real one for each app.
Six kinds of app, and who runs them with us
What moves each way, how it travels, and the client running it today, or an honest "no named client yet".
Payments and banks
Razorpay, Cashfree, your bank
Payments become receipts with the fee split out; bank lines match themselves.
Messages and calls
WhatsApp, SMS, telephony
Documents go out as messages; replies and call logs land on the record.
Government and checks
GST, e‑way bill, KYC, MCA
E‑invoices and e‑way bills from the invoice; PAN, Aadhaar and bank checks before money moves.
CRMs
HubSpot, Zoho CRM, Frappe CRM
Won deals become customers and orders; invoice and payment status go back to the deal.
Marketplaces and shipping
Amazon, Flipkart, Shiprocket
Orders in; each fee as its own line; settlements matched; tracking back.
Built in code, the same five ways, every time
Not a no-code tool's recipe: code we write, test and keep, so a bad day upstream never means a missing invoice.
- Signed
- Every incoming call's signature or token is checked before anything is read.
- Logged
- Every call and answer, searchable by order or invoice number.
Which way each event travels
Four ways; most connections use two or three.
| Way | We use it when | For example |
|---|---|---|
| Webhook | the app can tell us the moment something happens | Shopify order paid · Razorpay payment captured · ERPNext invoice submitted |
| REST API | we read or write one record | ERPNext, Zoho Books, SAP Business One Service Layer |
| GraphQL | the app speaks it, or one screen needs several systems in one query | Shopify's Admin API · a gateway over the books and the store |
| Scheduled pull or file | the app can't push, or has no API | Marketplace settlement reports · bank statements · Busy or Marg exports |
Code you own, run by the people who wrote it
Step 1
Map it
Every field, which side wins when both change, and what happens on a failure. Written down before any code.
Step 2
Build it
In your Git from day one. Tested against sandboxes, switched on one flow at a time.
Step 3
Run it
Alerts to your team, a queue you can see, fixes under support. On your server or ours.
What buyers ask before we wire anything
Yes. Every ERPNext record type is readable and writable over REST, and ERPNext can send a webhook when a document is saved, submitted or cancelled. We connect as an API user with only the roles the connection needs, so a leaked key can't touch payroll or settings. Nothing needs installing on ERPNext for most connections; our Medusa connector runs entirely outside it.
Yes. TallyPrime accepts vouchers as XML over HTTP, and as JSON from release 7.0. We post each voucher with its source id so nothing posts twice, and queue anything Tally rejects. The one limit: Tally answers only while it is open on a machine the connector can reach, so we set that machine up with you. Tally: stay, connect it or move.
Rarely. We write the connection as code you own: it is tested, versioned in your Git and watched. For light follow-ups that a marketer wants to edit without a developer, n8n has a place, and our marketing automation page covers it. Orders, payments and stock always go through code with retries and a nightly check.
It retries on a back-off, then waits in a queue your team can see, and an alert goes to whoever you name. When the other side is back, the queue replays and each event posts once, because every event keeps its own id. A nightly job compares both sides and lists anything that still differs.
Where it fits. Shopify's Admin API is GraphQL, so stock and fulfilment go back to Shopify that way. When one screen needs data from the books, the store and the CRM at once, we build a small GraphQL gateway over them. ERPNext itself speaks REST, and we use it as it is.
Usually. Where your bank gives you corporate API access, we pull statements and payouts through it; otherwise we import the statement file on a schedule. Either way each line is keyed by its UTR and matched to the invoice or bill it settles, and anything unmatched is listed for your accountant. ERPNext's built-in bank feed doesn't cover Indian banks.
You do. It sits in your Git from day one and the IP is assigned to you in the contract. It runs on your server or on ours, and the same people who wrote it keep it running under support, with alerts going to your team as well as ours.
Yes, through their seller APIs for orders and stock and their settlement reports for money. Each fee, such as commission or shipping, posts as its own line, and each settlement is matched to the orders it pays out. We don't have a named client on a marketplace connection yet, and we'd say so on a reference call.
It depends on how many flows you need and on the other app's API. After a call we write a plan that lists each flow, which way it runs, what happens on a failure, and the time and cost for each. Prices sit in that plan, not on this page.