Your ERP stays where it is; the CRM talks to it.
Account, balance, order and invoice data stays in the ERP; your sales team sees the same data in the CRM. We build the connection ourselves, using REST API, OAuth2, webhooks and import/export. This page describes the framework that stays the same whatever your ERP is called.
ERP and CRM do not do the same job — where exactly is the line?
The debate between ERP and CRM comes from the fact that both systems use the same words. Both have a “customer”, both have a “product” and a “price” — but they do not mean the same thing.
- The ERP records work that has already happened. The order was entered, the goods shipped, the invoice issued, the payment collected. The accuracy of the record carries financial and legal consequences; that is why an ERP is conservative, and it should be.
- The CRM records work that has not happened yet. Who called, what was discussed, which quote was given, why it was lost. A record here is not a document but a possibility; it is normal for it to change often.
- The gap sits between the two. One question sums it up: when does the person writing the quote find out that the company across the table has an overdue balance? The ERP knows this; the person writing the quote does not.
Integration work means closing that gap, and it is finished when four questions are answered: which field, in which direction, how often, on which key. The fourth is less visible than the other three, because its answer only emerges once you put the records side by side: which field matches the same company across the two systems? In our own installations that field is the tax identification number, not the trade name — because a name can be written “A.Ş.” in one system and “AŞ” in the other, and a match built on the trade name disappears silently.
We draw up this four-line table in the discovery call and hand it over in writing; if a line stays empty, we write it down as empty. When an empty line gets filled in halfway through the project, the field mapping and testing done up to that point have to be revisited — we have seen this in our own projects. That is why the table is filled in before the work starts.
Why the connection is not an out-of-the-box module
There is no out-of-the-box module for any ERP, and we will not claim there is. The connection is built as an integration project whose scope is determined in the discovery call, using the REST API, OAuth2, webhooks and import/export.
The proof that this is not a bluff is in how the product is actually used: in a live customer installation today, a third-party ERP integrator reads and writes records over that same REST API. We do not name them, because we do not have permission to publish the customer's or the integrator's name. And let us not overstate it: this is a single installation, not a list of case studies.
These are the tools we have:
- REST API — the product ships with 183 business objects out of the box, and each one is published in the REST API with its own data and schema endpoint; you can read the field structure from outside with
describe. Authentication is via OAuth2;compositesends 25 sub-requests in a single call, and bulk endpoints carry 200 records per call. - Outbound webhooks — a signed notification is sent to your system on record creation and change events; the receiving side verifies the signature to filter out forged notifications, and failed calls are retried.
- Import — a four-step wizard: upload, map fields, preview, run. More than 75 objects are supported; there is a limit of 25 MB per file and 100,000 rows per job, and you confirm the mapping on screen. Export is done in the same module; we have not measured its limits, so we are not putting a figure here.
So why do we not write a plug-in that works the same way for every customer? Because access on the other side changes from installation to installation: the ERP's version, the licence scope, which modules were bought and where the system runs — on-premise server or hosted — determine the method. Handing everyone the same button and saying “it works the same in every installation” would be a promise that fails as soon as the access conditions change.
For the general framework, see the integrations page. We also cover how the same framework looks for a single ERP on our Netsis integration page, and — for readers who want the two paths side by side with a decision criterion — on a separate page comparing a built-in connection with a project-specific integration.
Wednesday, 10:40 — IT, sales and finance around the same table in the discovery meeting. Six decisions come out of it:
-
1
Each field's authority is assigned to one side
Trade name and tax number stay in the ERP; conversation history and quotes stay in the CRM. No field is left with two owners: if the same field is updated independently in two places, nothing decides which value is valid when the two diverge.
-
2
The matching key is chosen, the exceptions listed
The tax identification number is taken as the key; the trade name is used only for verification. A list of records with no key is drawn up, and the meeting decides whether they should be merged or left to be handled manually.
-
3
The direction of flow is written down field by field
Balance flows from the ERP to the CRM; the order details of a won opportunity flow from the CRM to the ERP. If a field is to work in both directions, the conflict rule — which side wins in a contradiction — goes on the same line.
-
4
Frequency is a business decision, not a technology preference
Balance visibility can be achieved with a daily transfer; if it needs to be closer to the event, the method shifts to the REST API and webhooks. As frequency goes up, scope and cost change, which is why the business side makes this call.
-
5
Whether the ERP can be reached from outside is answered
If there is access, we talk about the REST API; if not, the flow is built on periodic import/export. Both work; the difference is latency and maintenance load. If the access conditions change later, the same scope moves onto an API-based flow.
-
6
Who will write the connection is decided
Both paths are open: we write the connection, or your partner who knows the ERP side writes it themselves over that same REST API. In the second case we provide the schema, the OAuth2 access and the field mapping table.
Flows that can be built between the ERP and the CRM
Account matching and duplicate clean-up
Accounts in the ERP are linked to company records in the CRM using the tax identification number as the key. Records whose key does not match are filtered out during setup; the matching rule lives in the written scope, not in someone's memory.
Visibility of balance, due dates and credit limit
Fields such as open balance, overdue amount and credit limit are transferred onto the company record. The transfer frequency — daily, weekly or periodic — is set in the scope, and the values are visible on the quote screen.
Tracking document data
Order and invoice headers are tracked as a list on the company record. Authority over the document stays in the ERP; the CRM does not produce documents, it adds a visibility layer for the sales team.
Product and price list transfer
When product records and the price list are transferred from the ERP to the CRM, quotes are written at the current price. The transfer can be periodic or set up over the REST API; authority stays in the ERP.
Passing a won opportunity to the ERP side
A signed webhook that passes the order details to the external system when an opportunity is won can be set up. Entering the same data a second time by hand on the accounting side is reduced; which fields are sent is written into the scope.
Defining the CRM equivalent of ERP fields without writing code
An administrator defines the CRM-side equivalent of fields such as credit limit, payment terms, dealer code or region without writing code. Adding custom fields and custom objects is standard in the product.
Four methods — which one, when?
| Method | What it does | When it is preferred |
|---|---|---|
| REST API (183 business objects, each with its own data and schema endpoint) | An external system reads and writes records in the CRM; it is authorised with OAuth2, the schema is read with describe, and composite sends 25 sub-requests in a single call | When suitable access exists on the ERP side and the flow is expected to run close to the event |
| Outbound webhook | Events in the CRM are delivered to the external system with a signature; the receiver verifies the signature and failed calls are retried | For flows that need notification from the CRM towards the ERP, if there is an endpoint on the ERP side to listen |
| Import (Data Hub) | Excel/CSV extracts are transferred with a four-step wizard: upload, map fields, preview, run. 75+ objects, 25 MB per file, 100,000 rows per job. Export is done in the same module; we have not measured its limits | It requires no API access on the other side, so it can be started before the access question is answered; when a periodic sync is enough, or when the ERP cannot be reached from outside |
| Third-party integrator | Your partner who knows the ERP side can write the connection themselves using that same REST API; we provide the schema, the OAuth2 access and the field mapping table | When you want to keep working with the firm that implemented your ERP |
What we have verified
How an ERP connection is put live
-
1
Discovery and access assessment
We establish your ERP's version, licence scope, which modules you use and where the system runs. We recommend that the partner who implemented your ERP, or your IT lead, joins this call; they hold the answer to the access question.
-
2
Field mapping table and written scope
Which field flows in which direction, how often, and the conflict rule are written line by line. The method is chosen here; the scope and any cost are shared in writing before work starts. The table is filled in first and the work starts after, so no surprise item appears.
-
3
Configuration and a test transfer with sample data
Fields, lists and permissions on the CRM side are set up; a test transfer is run with a sample of a real extract. Matches are verified on the key field, duplicate records are filtered out and faulty rows are reported.
-
4
Training, go-live and maintenance responsibility
Team training and close follow-up in the first week. Who updates the mapping table when a field or version changes in your ERP is written into the scope; when a flow stops, you know who to contact.
Three things we do not promise — and the long reasons why
-
1
We do not promise real-time stock synchronisation
Authority over the stock record stays in your ERP or warehouse system. We do not offer a live two-way stock mirror as a measured capability; if we did, it would produce two stock figures that do not agree. Instead we build a visibility layer with a defined scope.
-
2
We do not say orders, invoices and payments flow on their own
The chain is built into the product and can be switched on or off per installation; turning a quote into an order runs through a built-in action. But we do not think it is right to sell this as an automated accounting flow — producing official documents is not our job.
-
3
We do not promise production and MRP automation
Bill of materials, production line and work order screens exist in the product, and the BOM side has been set up with real data. But we cannot today point to a customer using work order execution; we do not sell what we cannot demonstrate.
What the three have in common — and how this page relates to the short version
This page is the long reasoning; the short verdict sits elsewhere. The one-sentence verdict on the three things we do not promise, and what we do instead, is in the limits section of the integrations page: a three-line table, for a quick look. The reasons are written out at length here. We split the work this way so that we do not end up with two different sentences in two places — the verdict there, the reasoning here.
What the three have in common is this: all three promises would require taking authority over the data away from the ERP and moving it to the CRM. A CRM that does this starts to replace the ERP; and replacing the ERP is not an integration project but an ERP replacement project, and that is not our line of work.
A sync and a mirror are not the same thing. Copying a field between two systems does not on its own count as a sync; a sync also requires defining which side wins in a contradiction. How often that rule comes into play is determined by how fast the field changes: a balance may change a few times a day, stock within minutes. When the rule fires, the losing side shows the wrong number; seeing the wrong stock figure on the sales screen has a different consequence from seeing no stock figure at all — because a promise is made to the customer on the strength of the number that was seen.
What do we do instead? We leave authority where it is and move visibility. For stock, a visibility layer with a defined scope and frequency; on the document side, carrying the number, date and amount across as fields; in production, setting up the bill of materials and the line definition, but not claiming that planning is run from the CRM. The same criterion applies to all three: we sell what we can demonstrate with a customer using it.
e-Fatura and e-Arşiv: Rapitek CRM does not issue official documents and is not a GİB-accredited special integrator; the product has no fields such as ETTN or GİB status. Your invoices continue to be issued by your current provider; the invoice number, date and amount can be carried onto the company record over the REST API or by periodic import.
Data location: your data is held in the European Union — the database in Helsinki (Finland), the files you upload in Frankfurt, and database backups in Falkenstein (Germany). We have no component in Türkiye and we do not have a region selection feature. This is a transfer abroad under KVKK art. 9; we establish the basis for that transfer together during the contract process. The details are on the security page and in the KVKK privacy notice.
Certification: we do not hold an ISO 27001 or SOC 2 certificate, and we will not claim one until we do. We fill in your enterprise security assessment forms and describe the architecture in writing.
Scope comes out of discovery; plan prices are in the open
The cost of an ERP connection depends on data volume, the direction of the flow and the access available on the other side; it is shared in writing after discovery. We publish plan prices and separately priced items on a single page.
Three plans, a scope table and separately priced items on one page.
Frequently asked questions about ERP–CRM integration
We already have an ERP. Why would we need a CRM?
What does ERP CRM integration mean in practice, what actually gets done?
Is there a ready-made ERP module in Rapitek CRM?
Has anyone actually used this API so far?
Which ERPs do you work with?
Which field is used to match companies across the two systems?
Our ERP server cannot be reached from outside. Is integration still possible?
Can our own ERP partner write the integration?
Why is stock synchronisation not promised?
Can we issue e-Fatura from the CRM?
Is synchronisation real-time?
How is the cost of the integration determined?
How long does implementation take?
Will we lose data when we move our ERP data into the CRM?
Where is our data held?
Is your ERP on this list?
Netsis integration
Which direction account, balance, order and invoice data flows in; choosing a method for an installation running on an on-premise server.
Nebim integration
How the retail and wholesale channels are kept apart in the same CRM; the flow of dealer balances and the seasonal price list.
Logo integration
Scope for installations using Tiger, Go and j-Platform; the effect of a version upgrade on the field mapping table.
Mikro integration
Connecting to the commercial and accounting software: account records, balance and invoice data visible on the sales screen.
SAP integration
Scope, choice of method, and written answers to the security questions IT will ask.
Paraşüt integration
The pre-accounting side: account and collection visibility; what we do and do not do about e-Fatura.
Luca integration
How the flow is built when your accounting sits with your financial adviser, and the scope of periodic transfers.
Built-in connection or project?
The decision criterion: when a connection configured during setup is enough, and when a project-specific integration is required.
Integrations
The connections working in the product today and the ones we build on request; the short verdict on the three things we do not promise.
Security
Which country the data sits in, the list of sub-processors, backups, audit trail and what we do not offer yet.
Let's answer the four questions together in 30 minutes
Which field, in which direction, how often, on which key — in the demo call let us start filling in this table against your own ERP, and choose the method and the scope together.
The scope of the implementation, and any cost, are worked out in the discovery call and shared in writing.
