EspoCRM REST API integration guide

Why EspoCRM REST API integration needs design before the first call

The REST API is the supported way to connect EspoCRM to web forms, ERP accounts, mail and call logs, and the hard part of that work is not the endpoint calls. It is deciding which identity each system writes under, what each identity is allowed to change, and what happens when a write fails or arrives twice. Teams that start by mapping URLs usually discover these questions after data has already been duplicated or overwritten. Integrations look simpler than they are for three reasons. First, the same record is often changed from several places at once: a sales rep edits an account in the UI, an ERP job updates billing details overnight, and a web form creates a contact for the same person. Second, EspoCRM does not give you a shared identifier across systems by default. Your web form, ERP and telephony platform each hold their own keys for the same customer, so you must decide which system owns the match and store cross-reference IDs deliberately. Third, API behavior is tied to the version you run. Before writing code, confirm field validation, duplicate handling, and error responses against the exact EspoCRM release in your environment, using its own API documentation and a test instance rather than assumptions from older versions. Identity comes first. The REST API supports API key, HMAC and basic authentication through dedicated API users with role-based permissions. Create one API user per integration, not a shared admin account, and give each user only the entity permissions its job needs. The EspoCRM documentation describes HMAC as the most secure of these methods and basic authentication as not recommended, so plan HMAC unless a specific constraint in your environment rules it out. Ask your team to document which integration writes which entity and which fields, because that document becomes the basis for every permission and every reconciliation rule later. Failure handling needs the same attention as the happy path. A web form that times out may or may not have created a lead, and a retry without a check can create a second one. Decide in advance how each integration detects existing records, whether it queues failed writes for replay, who is alerted, and how a bad batch is reversed. EspoCRM's import tooling supports duplicate matching on chosen fields and reverting imported records, which is useful for one-off loads, but live integrations need their own matching logic and logs. Before the first call, produce four things: an integration inventory with owners, an API user and role matrix, a written duplicate and conflict policy, and a test plan run on the exact EspoCRM version you will operate. Identity provider setup, security hardening and platform migration each have their own topics on this site, so this section assumes those foundations are in place or planned separately.

Which EspoCRM components an integration touches

A REST API integration with EspoCRM touches more than the endpoints themselves. Authentication, the permissions behind each API user, server-side scripts that run on writes, and scheduled background jobs all shape what an external system can read, change and rely on. Reviewing each component before design starts makes the build and its failure modes easier to plan.

Entity read and write endpoints

The REST API exposes entities such as accounts, contacts, leads and opportunities as resources that external systems can read, create, update and delete. Each call is evaluated against the permissions of the user it authenticates as, so the same request can succeed for one user and fail for another. Confirm which entities and fields each integration needs, and test list and update calls against a staging instance before any production write.

Dedicated API users and roles

EspoCRM API access runs through dedicated API users, each bound to a role that controls entity access, field visibility and record scope. Giving an integration a separate user keeps its activity distinct in audit history and lets its permissions be narrowed without affecting people. Review the role for each integration to confirm it grants only the create, read and edit rights its scope requires, and avoid reusing an administrator account.

Authentication methods

The API supports API key, HMAC and basic authentication. The EspoCRM documentation describes HMAC as the most secure of these and advises against basic authentication. Choose the method per integration based on what the calling system can sign or store securely, and confirm how credentials are rotated and revoked when an integrated system is retired.

API before-save scripts in Formula Script

API before-save scripts run Formula Script logic when records are saved through the API, which can set defaults, validate values or derive fields before the write completes. Because they apply to API traffic, they can change results for an external system that expects the raw values it sent. Document every script that affects an integration, check how it handles empty or unexpected input, and test it with the same payloads the external system will send.

Cron and scheduled background jobs

EspoCRM relies on cron or an equivalent scheduled task to run background jobs, and some sync or import work depends on those jobs completing. If the schedule stops or runs late, queued work can stall without an obvious error in the integrated system. Confirm the scheduler is configured on the host, monitor that jobs complete, and agree with the integration owner how delayed processing will be detected.

Advanced Pack workflows as an outbound trigger

The Advanced Pack, which is included in all EspoCRM Cloud plans, provides workflows and Business Process Management that may serve as a path for pushing record changes to external systems. Whether a given workflow action can make the outbound call a specific integration needs depends on the action types and the target system, so it must be confirmed for each use case. Check the Advanced Pack documentation and test the trigger path under realistic load before relying on it.

Which authentication method and integration pattern to choose

This table compares the three EspoCRM REST API authentication methods and two integration patterns, showing when each fits and what it costs to operate. Read each row against your own client count, key rotation policy and latency needs. The main takeaway is that HMAC is the method the EspoCRM docs describe as most secure, and that dedicated API users per integration keep permissions and revocation manageable.

Option	When it fits	Operational cost
API key	Single trusted server-side integration with low change frequency and a documented rotation procedure	Key must be stored and rotated in each system that holds it; a leaked key grants the API user's full permissions until revoked
HMAC signed requests	Integrations that send sensitive data or need the strongest method the EspoCRM docs describe	Signing logic must be built and tested in every client; clock and canonical string mismatches are common sources of failed calls
Basic authentication	Only as a short-lived test against a non-production instance	Not recommended by the EspoCRM docs; credentials travel with every request, so avoid it outside controlled testing
Dedicated API user per integration	Each website, ERP, email or telephony connector needs its own permissions and audit trail	More users to create, review and deactivate; role design must be repeated per integration
Shared API user across integrations	Small estate with one connector and one team owning all integration changes	A single compromised or misconfigured integration affects every other connection; audit logs cannot separate sources
Push from the source system	Source system emits events on change, such as a website form or ERP order, and needs fast updates in EspoCRM	Requires the source to handle retries and failures; receiving endpoints must be reachable and secured
Poll EspoCRM on a schedule	Source cannot send outbound calls, or a batch window is acceptable	Polling load grows with frequency and record count; latency equals the polling interval, and duplicate handling must be designed in

How to build the EspoCRM API integration step by step

This sequence takes a connection from an agreed data contract to a monitored, retry-safe integration with each source system. Each step closes with a check you can run, so the integration is proven at every stage before the next one starts.

Define the integration contract
Before any configuration, the integration owner and the owners of each source system agree on the entities in scope (typically accounts, contacts, leads, opportunities or custom entities), the fields on each, and the direction of data flow for every field. For each field, name one owner who decides its value and who fixes it when it is wrong. Record the duplicate rule as well, meaning which fields identify the same record across systems. The step is done when the contract is signed off in writing and every field has exactly one owner. Ask your EspoCRM partner to walk through the contract against your existing Entity Manager setup, so gaps in custom fields surface now rather than during testing.
Create a dedicated API user with narrow permissions
Create a separate API user in EspoCRM for each source system instead of reusing a person's account or an administrator account. Assign a role that grants only the entities and actions in the contract, such as read and create on leads but no delete permission on accounts. Keep the user out of teams that expose records it should not see. The check is a test record created through the API user, then viewed in the EspoCRM interface under that user's permissions, with a confirmation that a request for an out-of-scope entity is refused. Confirm this behavior in your own EspoCRM version, since role options depend on the release and extensions installed.
Choose and configure the authentication method
EspoCRM's API supports API key, HMAC and basic authentication through dedicated API users. The EspoCRM documentation describes HMAC as the most secure option and does not recommend basic authentication, so plan around HMAC unless a source system cannot sign requests. Generate the credentials for the API user, store them in the source system's secret store rather than in code or configuration files, and set up the signing logic on the calling side. The check is a successful authenticated read of one known record, followed by a deliberately wrong signature being rejected. Confirm which method each of your source systems can support before committing.
Test read and write calls on a non-production instance
Run every call in the contract against a non-production EspoCRM instance that mirrors your production configuration, including the same custom entities, fields, layouts and roles. Start with reads, then creates, then updates, and finally the duplicate scenario, so each class of call is proven before the next. Use records tagged as test data and keep a list of the IDs created so they can be removed afterward. The check is a complete test log in which each call shows the expected response and the record appears in the interface with the expected values. Do not move to production until the duplicate and error cases produce the outcome written in the contract.
Add API before-save scripts for validation
Where incoming data needs checking or cleaning, add API before-save scripts using EspoCRM's Formula Script in the Entity Manager. Use them to validate required values, normalize formats such as phone numbers or country codes, and reject records that break the contract, so bad data does not reach the CRM. Keep the logic in the scripts small and documented, because every source system depends on it. The check is a set of test payloads, both valid and invalid, that produce the expected stored value or rejection message. Ask your partner to confirm how the scripts behave after upgrades, since custom logic should be reviewed during each upgrade.
Wire each source system to the API
Connect the source systems one at a time, starting with the one that carries the least risk, such as a website form, and finishing with the one that holds the most authoritative data, such as an ERP. For each system, map its fields to the contract, configure its outbound calls or inbound polling, and point it at the non-production instance first, then promote the same configuration to production. Where webhooks are used, confirm the receiving endpoint is protected and that its payloads match the contract. The check is one end-to-end record that starts in the source system, appears in EspoCRM with the correct owner and values, and returns the expected confirmation to the source.
Set up logging and retry handling
Log every API call with a timestamp, the calling API user, the entity, the record ID and the response status, and store those logs outside the application so they survive a failed server. Add retry logic on the calling side with a limit on attempts and a clear rule for when a failed record goes to a manual queue. Define who reviews the queue and how often. The check is a deliberately induced failure, such as a stopped network path or an invalid payload, that produces a log entry, triggers the expected retries and lands in the review queue without creating a duplicate record. Confirm the retry behavior with each source system's owner, because some platforms retry automatically and can create duplicates unless the receiving side is idempotent.

How to handle sync errors and duplicate records from API writes

Duplicates from API writes are a design problem, not a bug you can fix later. When a source system sends a create request, receives no response because of a timeout or network drop, and sends it again, EspoCRM may end up with two contacts or two leads for the same person. The same thing happens when a partial failure leaves a parent record written and its child records missing, or when two systems update the same field in different orders. Before you write any integration code, decide how each source system will recognize a record it has already sent, and how EspoCRM will recognize it too.

Start by assigning a stable external identifier to every record that crosses the boundary. In practice this means a custom field on each relevant EspoCRM entity (for example, a text field for the ERP customer number or the website form submission ID), set through the Entity Manager and exposed in the layouts your API user can read. Confirm that the field is indexed and that it is unique where your design requires it. Then document, for each source system, which value it owns and whether EspoCRM ever overwrites it. An identifier that changes between systems, or that is reused after deletion, will defeat every later control.

Idempotent write design means the same logical request can be sent twice without creating a second record. The usual pattern is to look up the external identifier first and then choose between create and update, so that a retry becomes an update of the record that already exists. The CSV import docs describe duplicate matching on chosen fields and three modes, Create Only, Create and Update, and Update Only. Those choices are useful as a model for your API logic, but they do not carry over automatically. You must design the same matching rule and the same mode decisions for each API endpoint you call, and test them. Confirm on your deployed version how the REST API reports validation and duplicate conflicts, which error codes it returns and how it behaves under request bursts, because these details vary by release and by how the instance is configured. The documentation for the version you run is the authority here.

Your retry policy should distinguish between failures that are safe to repeat and failures that are not. Timeouts and server errors on updates can usually be retried with backoff, provided the write is idempotent. Creates should not be resent blindly: before a retry, query by the external identifier, and only create if nothing is found. Set a maximum number of attempts, log every failed request with its identifier and payload hash, and route exhausted failures to a dead-letter queue that a person reviews. Ask your integration team to show you what happens when a request times out after EspoCRM has already committed it, because that is the case that produces duplicates.

Even a well-designed integration drifts, so plan a reconciliation job that compares source and EspoCRM on a schedule. The job should pull records by external identifier from both sides, flag records missing on either side, flag field conflicts, and flag duplicates by matching rules, and it should write a report rather than silently fixing data. Decide in advance which system is authoritative for each field and who approves corrections. Run the job against a copy of production data before you trust it, and record how long it takes at your record volumes, since that figure will determine how often you can run it.

What drives the effort and cost of an EspoCRM API integration

This table lists the factors that most change the effort and cost of an EspoCRM API integration, how each one grows the work, and how to keep it contained. Use it to check that a written scope covers each driver, so that quotes from different partners can be compared line by line. The main takeaway is that the number of bidirectional fields and the number of systems writing to them usually matter more than the connection itself.

Driver	Why it changes effort or cost	How to keep it down
Number of source systems	Each system adds its own data model, credentials, error handling and test cases, and every extra pair of systems can create new conflicts.	Confirm which systems read and which write. Connect each system through one agreed integration layer where possible.
Entities and fields written in both directions	Bidirectional writes on accounts, contacts, leads or opportunities require conflict rules, timestamps and reconciliation. This is often the largest share of build and test effort.	Narrow the field set to those that truly need two-way sync. Make the rest read-only in the direction they are needed.
Push from one system of record	Pulls and pushes from several systems into the same records multiply edge cases and make audit trails harder to explain.	Name a single system of record for each entity and field group, and document it in the scope before build starts.
Authentication choice and key management	API key, HMAC and basic authentication use different credentials, rotation steps and secret storage. Per-integration API users with narrow roles add setup and review work.	Use dedicated API users with role-based permissions. Confirm the chosen method with the security owner, and agree who rotates keys and where secrets are stored.
Volume and frequency of events	High event rates, bulk loads and webhooks that fire on every save need queuing, retries, rate handling and load testing. Scheduled batch syncs are simpler to test.	Agree expected record counts and peak times in writing. Batch low-priority updates and limit webhooks to the events the receiving system needs.
Custom entities and before-save scripts	Custom fields, Formula Script logic in API before-save scripts and custom entities must be mapped, tested and kept upgrade-safe. Each script can change what an API call returns.	List every custom entity and script in the scope. Reuse existing fields where they fit, and review each script against upgrade plans.
Environments (dev, test, production)	Separate instances, test data, sandbox credentials and deployment steps for each environment add cost. Shared test systems often cause data leaks between teams.	Confirm which environments are in scope, who provides them and how test data is seeded and reset. Ask for a documented promotion path.
Compliance logging needs	Audit logs of who changed what through the API, retention periods and evidence for assessors require extra design and storage. These needs often appear late.	Agree the required log fields, retention and access rules before build. Ask the client compliance lead to confirm which evidence they need.
Duplicate handling and error recovery	Matching rules, retry logic and reconciliation reports for failed or duplicate writes add test effort and ongoing operational work.	Define duplicate matching fields and an error queue owner. Agree how failed records are reviewed and reprocessed.

How to secure API users, keys and credentials

Every system that calls the EspoCRM REST API is a identity with access to customer data, so it needs the same discipline as a person. The cards below cover the decisions that control what an integration can reach, how it proves who it is, where its secrets are kept and how access is withdrawn when it changes.

Dedicated API users with least-privilege roles

Create one API user per integration, such as the website form handler, the ERP sync or the telephony connector, and assign each a role that grants only the entities and actions that integration needs. A website form that creates leads should not be able to read accounts or delete records. Before go-live, review the role in the administration area and test each call the integration makes against it, so that permission errors surface in staging rather than in production.

No admin accounts for integrations

Integrations must never authenticate as an administrator, even temporarily during setup. An admin credential carries rights to change roles, users and settings, so a leaked key would expose the whole instance. The EspoCRM security documentation advises against using admin accounts for routine work, and the same principle applies to machine users. Ask your partner or internal team to confirm that no integration key belongs to an account with administrator rights.

Choose HMAC signing over API keys

The EspoCRM API documentation describes HMAC as the most secure of its supported methods, with API key and basic authentication as the alternatives, and it does not recommend basic authentication. HMAC signs each request with a secret so the secret itself is not sent with every call. Decide which method each integration uses, confirm that the calling software supports request signing, and document the choice, because switching later means changing every client.

Keep secrets out of source code

API keys and HMAC secrets belong in a secrets manager or an environment store managed by the hosting platform, never in repositories, configuration files committed to version control, or website templates that browsers can read. Check the integration's codebase and deployment pipeline for hard-coded values, restrict who can read the secret store, and log access where the store supports it. Confirm with your internal team which vault or store each integration will use.

Rotation and revocation procedure

Each API user should have a named owner, a documented rotation schedule and a tested way to disable the credential immediately. Rotation means issuing a new secret, updating the calling system, confirming traffic moves over and then retiring the old one. Revocation must be possible within minutes when a developer leaves or a host is compromised. Write the steps down, practice them once in a non-production instance, and record who may perform them.

IP restriction for calling systems

Where EspoCRM's access controls allow it, restrict each API user to the fixed addresses of the systems that call it, such as the web server, the ERP host or the telephony gateway. The EspoCRM security documentation lists IP-based restriction as a recommended control. Confirm the calling systems' outbound addresses before enabling it, because cloud hosts and shared proxies can change them, and test that a call from an unlisted address is refused.

How to test that the integration works and fails safely

The test plan for an EspoCRM REST API integration should prove two things: that the happy path writes correct data through the API user you configured, and that every failure mode leaves CRM data consistent and recoverable. Run these tests against a dedicated test instance with its own database, API users and integration credentials before any production cutover. Keep the test instance on the same EspoCRM version and the same authentication method (HMAC or API key, as chosen in the design) that production will use, so the results carry over.

Start with the functional cases. Create, update and read one record of each entity the integration touches, such as Account, Contact, Lead or a custom entity, using the API user's role and not an administrator account. Then run the negative permission case: send a write that includes a field the API user's role does not allow to be edited, and confirm EspoCRM rejects it or ignores it as designed, and that the field value is unchanged afterwards. Repeat for an out-of-scope entity. Record the exact HTTP status codes and response bodies, because your error handling in the connector depends on them. Confirm these against the EspoCRM API documentation and your own tests rather than assuming them.

Next, test malformed and duplicate input. Send payloads with missing required fields, wrong data types, invalid enum values and oversized text, and confirm each one produces a clear error that your connector logs without retrying forever. For duplicates, submit the same web form or ERP event two or three times, both quickly and after a delay, and then count records matching the duplicate-check fields you chose. Your connector should use a stable external identifier or a lookup before create so that a repeated event updates the existing record. Query the database or use list views filtered by that identifier to confirm there is exactly one record per source event.

Then simulate timeouts and outages. Force an upstream timeout by delaying the connector's call past its client timeout, so that EspoCRM may have committed the write while the caller believes it failed. Retry the same event and confirm the retry does not create a second record. Next, stop the EspoCRM application or its database during a write burst, and confirm that every event either succeeds after recovery or lands in a durable queue or error log with its full payload and timestamp. Verify the replay by draining that queue after EspoCRM returns. No event should be lost, and no record should appear twice. Who owns the queue, how long failed events are kept, and who is alerted are decisions to settle before this test.

Finish with cleanup and evidence. Delete or revert all test records, using a tagged test identifier so the cleanup is repeatable, and confirm that counts return to their baseline. Keep the test scripts, payloads, logs and results as a dated record that your security or compliance reviewer can inspect. Keep test data strictly separate from production: separate hosts, credentials, webhook endpoints and email sending, so a test event cannot reach a real customer or an ERP ledger. Confirm this separation in writing as an exit criterion.

How the integration design changes by deployment model

A single-server install, whether built with the EspoCRM installation script (which deploys a Docker-based stack with Nginx and MariaDB) or with a manual script-based setup on Apache, Nginx or IIS, keeps the whole integration path on one host. The API is reached at one hostname, so the design question is mostly about how much of that host is visible to the systems that call it. Teams usually put the API behind the same TLS endpoint as the user interface, then restrict who can reach it.

What changes in this model:

Endpoint exposure: one public or internal hostname serves both the UI and the REST API. Restrict the API path by source address where your website, ERP or telephony platform calls from fixed IPs.
Certificates: one certificate covers the instance. The installation script can request Let's Encrypt certificates, so confirm renewal works and that the outbound port needed for validation is open.
Outbound connectivity: webhooks and polling are simplest here, since the host usually has one egress path. Confirm which destinations it may call and whether a proxy is required.
Logs: web server, PHP and application logs all sit on the same host. Decide where they are rotated and shipped before the first integration goes live.
Backups: the command.sh utility covers backups and restores for the stack, so include integration credentials and API user settings in your restore test.

Before go-live, check which API users exist, what each role permits, and whether the chosen authentication method matches the security documentation's guidance on HMAC.

What to monitor, back up and document after go-live

After go-live, the integration needs watching on four fronts: API error rates, authentication failures, queue or retry backlogs, and the cron job health that background processing depends on. Set alerts on each before the first production sync, not after the first missed order. Track HTTP error responses from the EspoCRM REST API by endpoint and by API user, so a permissions change on one integration account shows up as a spike rather than a vague complaint from the sales team. Authentication failures deserve their own alert, since an expired or rotated API key typically looks like a sudden wall of 401 or 403 responses from a single calling system.

Queue and retry backlogs are easy to miss because the CRM still looks healthy while data quietly stops moving. Ask your partner or internal team to define what the sending system does when EspoCRM is slow or rejects a record: does it retry, park the message, or drop it? Measure the size of that queue daily and agree on a threshold. Cron health matters just as much. EspoCRM needs a scheduled task to run background jobs, and asynchronous work such as large imports, queued actions and scheduled workflows stops silently if that task fails. Confirm where cron logs are written, how a failed run is detected, and who receives the notice. Verify the cron entry is still present after any server maintenance or OS patching.

Backups for this integration must cover two things: the database and the file storage. The database holds records, relationships, and API user settings, while the file storage holds attachments, imported source files and other uploaded content that the database points to. A database-only restore leaves broken references. Confirm with your hosting or DeployOpen's proposed design which backup tooling is used, where copies are stored, how long they are kept, and whether the backup set is encrypted. The EspoCRM installation docs describe a command.sh utility for backups, restores and upgrades in script-based Docker installs, but your environment may differ, so check its exact behavior. Restore testing on a non-production copy is the only proof that a backup works. Schedule it and record the result.

An integration needs its own documentation, separate from the CRM administration guide. Write a runbook covering who owns each connected system, how to restart a failed sync, and how to pause one source without touching the rest. Keep a field contract that lists every field each external system writes, its data type, its allowed values and the system that is the source of truth for it. Maintain a key inventory of every API user, the authentication method in use (HMAC is the method the EspoCRM docs describe as most secure, while basic authentication is not recommended), the role assigned, the expiry or rotation date, and the systems holding a copy of the secret. Finally, write rollback steps for each release of the integration, including how to disable a broken mapping and how to revert records written in error. Test those steps before you need them.

Upgrades add a further operational duty. As of version 10, upgrading through the EspoCRM UI is disabled by default, so upgrades are run from the command line. Each upgrade should be followed by a full re-run of the integration tests: authentication for every API user, create, update and delete calls for each mapped entity, duplicate handling, and webhook delivery. Confirm with your team which tests exist today. If none are written yet, that gap should be closed before the first upgrade, because an upgrade that changes a field, role or validation rule can break a sync that looked correct the day before.

Common questions about EspoCRM REST API integration cost and effort

What drives the cost of an EspoCRM REST API integration?

The main drivers are the number of external systems, how many objects and fields move between them, and how strict the rules for matching and conflict resolution must be. A website form that creates one lead is far smaller than a two-way sync between an ERP and EspoCRM that touches accounts, invoices and orders. Cost also rises with the number of environments you need, the authentication method you choose, and the amount of error handling and monitoring you expect after go-live. Ask any partner to break the quote into discovery, build, testing, deployment and handover so you can see which parts scale with scope. EspoCRM itself is free to self-host under AGPL-3.0, so your spend is labor, hosting and any extensions, not a license fee for the API.

Can our in-house team build an EspoCRM API integration without a partner?

Yes, if you have engineers who know REST APIs, the target system's data model, and how to run a self-hosted application. Most of the risk sits in the parts that are easy to underestimate: deciding which system owns each field, designing duplicate matching, handling retries and partial failures, and keeping API users limited to the permissions they need. A team that has built similar integrations before can usually cover these without help. A team building its first integration typically benefits from an outside review of the field contract and the error design before go-live. Be honest about who will maintain the integration after launch, because that ownership question matters more than the initial build.

What do we need to provide for an EspoCRM integration project?

You will need named system owners for EspoCRM and for each connected system, someone who can answer questions about business rules within a day or two, and access to a test environment that mirrors production closely enough to trust the results. You also need a written field contract that lists each object, each field, its data type, which system is the source of truth, how values are transformed, and what happens when a value is missing or invalid. Provide sample payloads from every connected system, a list of expected volumes, and the security requirements your organization applies to service accounts and secrets. Missing any of these usually adds rework late in the project, so confirm them during scoping.

How long does an EspoCRM REST API integration take?

Duration depends almost entirely on scope. A single one-way push from a website form into EspoCRM, with one API user and simple validation, is a short project. A bidirectional sync with an ERP, duplicate handling, webhook events, and a formal test plan takes considerably longer because each additional object and each conflict rule adds design and testing work. Timelines also depend on how quickly your owners answer questions and how stable the test environment is. Do not accept a duration without a list of objects, directions of data flow, and environments in scope. Ask the partner to show which milestones depend on your team's decisions.

Is HMAC authentication worth the extra effort compared with an API key?

For most production integrations that move sensitive business data, HMAC is worth the added effort. The EspoCRM API documentation describes HMAC as the most secure of its supported methods, while basic authentication is marked as not recommended. An API key is simpler to set up and works well for low-risk, internal connections, especially when the API user has tight role permissions and the traffic stays on a private network. HMAC requires signing each request with a secret, so the calling system must compute signatures correctly and handle clock and secret rotation. Weigh the added build and testing work against the sensitivity of the data and how the calling system is secured.

How are sync errors and duplicates handled after go-live?

Good designs record every failed call with enough context to replay it, retry transient failures with limits, and route permanent failures to a person who can fix the data. Duplicate handling depends on agreed matching fields, such as an external ID or a normalized email address, and on whether the integration creates, updates or only reads records. EspoCRM's import tool supports modes such as Create Only, Create and Update and Update Only, plus duplicate matching on chosen fields and reverting imported records, which helps during migration and corrections. Ask any partner for a runbook covering monitoring, alert ownership, replay steps and who approves manual corrections, and confirm how long logs are retained in your environment.

What should we ask for in a quote for this integration?

Ask for a written scope that lists each connected system, each object, the data direction for each field, the authentication method, and the environments included. Request separate line items for discovery, build, testing, deployment, documentation and handover, and state whether each is fixed-price or estimated. Confirm what is one-time and what recurs, such as hosting, monitoring, patching and support after go-live, and whether ongoing support is covered by a retainer. Also ask what is excluded, how change requests are priced, and which acceptance criteria close the project. A quote that cannot be traced back to these items is hard to compare.

How DeployOpen works on this

DeployOpen plans, builds, documents and supports EspoCRM REST API integrations inside your own infrastructure, so the API users, authentication method and sync logic sit under your control. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every connected system, its data direction and the records each one reads or writes.
Choose API key or HMAC authentication per integration and define a dedicated API user with role-based permissions.
Define duplicate matching rules, sync error handling and which system wins when records conflict.

How we build

Create API users and roles with the minimum entity and field permissions each integration needs.
Build webhooks, scheduled sync jobs or formula before-save scripts, and test each path against a non-production instance.
Test failure cases such as timeouts, rejected payloads, duplicate submissions and partial updates before go-live.

How we hand over

Deliver written documentation covering endpoints used, credentials ownership, field mappings and rotation steps.
Provide runbooks for reviewing sync errors, re-running failed records and reverting bad imports.
Walk your administrators through monitoring, logs and the change steps needed when a connected system changes.

How we support

Review integrations before each EspoCRM upgrade, since API behavior and customizations can change between releases.
Offer ongoing support and continuous testing as a retainer, sized to the number of integrations you run.
Confirm with your team which support levels, response expectations and access arrangements apply before signing.

EspoCRM REST API integration