We design REST and GraphQL APIs and connect systems that do not talk to each other: ERP to CRM, ERP to WMS, accounting to payroll, legacy databases to modern applications. Based in Patras, working across Greece. The value of an integration is in the contract, the logging and the cutover plan — not in a vendor logo.
For an online store, see e-shop development with ERP integration — including Skroutz and BestPrice feeds.
The trigger is not “we want an API”. It is an event that already costs time or wrong data. If two teams open the same file, if payroll waits on a manual ERP extract, or if a public body requires certificate-backed calls you have not issued yet — that is an integration job, not a new screen. Discovery starts from the system pair and from what happens when one side is down, not from a framework choice.
REST fits stable resources and many consumers. GraphQL fits when each screen wants a different shape without extra fields. Data contracts lock fields, types and what empty means.
Versioning so a change does not break old clients. Pagination and rate limiting so one consumer cannot exhaust resources at the expense of others. Error semantics: which code is a retry, which is a final reject. Idempotency keys so the same POST does not create two records.
The contract is written before the code: fields, requiredness, what empty means, which error codes may be retried. Without that, two teams ship two different APIs under one name.
OpenAPI documentation is not an appendix at the end. It is the text both sides sign as behaviour: authentication, pagination, rate limits, error shape. If a field changes without a new version, old clients break silently. That is why versioning is a product decision, not a coding detail.
Authentication and authorisation, least privilege per client, encrypted transport, secrets out of source, audit logging, rate limits. Wider application hardening and incident response are covered under the cybersecurity service.
A webhook when the provider pushes events and you must react. Polling when there is no push. Batch when volume is large and delay is acceptable.
Queues and event-driven flows when upstream is slow. Middleware when many consumers share one contract. Sync when the answer must return in the same call; async when work finishes later. ETL and pipelines when you move history, not only live events.
The choice is not architectural taste. If the provider pushes an event, a webhook. If not, polling with a written interval. If the volume is a nightly catalogue, batch. Mix the three without a reason and you will not know where a record went.
This is the centre of the service. Without it, a “successful” call may have posted the same order twice — or not at all. Reliability is not “we will see at the end”: it is rules written in discovery — which system is source of truth per field, how long we wait before a retry, where a message goes when it fails for good, who watches the alert at 02:00. The runbook is handed to your team, so operations do not depend on one person.
After go-live, day-to-day operation and monitoring of the systems belong under IT support — not inside the integration scope.
Integration categories and status: implemented, or feasible after analysis.
We take these on after analysing access and a sandbox. Greek public and banking APIs often need certificates, signing roles and call limits that a generic tutorial does not publish — that is why we do not call them a deliverable until we see access, a sandbox and a legal signer.
Custom REST / GraphQL: APIs we design and hand over — implemented. There the deliverable is our own contract, OpenAPI spec and runbook, not a public endpoint without the client’s access.
myDATA is listed here as a general invoicing integration; per-order invoicing for an online store is covered under e-shop development.
ERP↔CRM: customers and opportunities agree without a manual CSV. Example pair: SoftOne to a CRM.
ERP↔WMS: warehouses and movements. Example: Pegasus to a WMS so floor stock does not drift from the ledger.
ERP↔BI: events into a reporting store, not “another spreadsheet”.
Legacy database to a modern API: we wrap the old source with a contract, auth and limits, without rewriting the whole app on day one.
Mobile-app backend: the same API the app consumes, with roles and pagination. Building the app is covered under the web-apps service.
Third-party SaaS: mapping to the format the vendor requires, with a queue when they are slow.
The app that consumes the API: the web app that calls the API.
Models as a service inside a flow: summary, classification, field extraction — not a decorative chatbot. Cost per call depends on volume; caching and rate limits so you are not billed twice for the same text. Failures: retry or a safe refuse, not a silent answer. Data protection: what leaves the EU and what stays.
When two systems do not talk, when transfer is done in Excel, when the legacy system has no API, or when a third party requires a specific format. A ready connector is enough only if it covers the fields and failures that matter to you.
REST when resources are stable and clients are many. GraphQL when the UI needs different shapes per screen without over-fetch. We do not pick GraphQL because it is fashionable.
Idempotency so a transaction never posts twice, retries with backoff, a dead-letter when it fails for good, a reconciliation report, an alert when sync stops, and a runbook for your team when upstream is down.
As a general invoicing integration, yes — feasible after analysis of credentials and the accounting shape. Per-order invoicing for an online store is covered under e-shop development.
As a public-API category: feasible after analysis. We do not call it a deliverable before we see the endpoint, certificates and who legally signs the call.
Yes. ERP↔CRM, ERP↔WMS, ERP↔BI and legacy-database-to-API are the core of this service. An ERP bridge for an online store is a separate service.
As a model-as-a-service inside an operational flow — caching, rate limits, failures and data protection — feasible after analysis. We do not publish a per-token cost without your volume.
An OpenAPI spec, call examples, a Postman collection, a runbook and training for the team that will operate the integration.
Authentication and authorisation, least privilege, encrypted transport, secrets management, audit log, rate limits. The wider attack surface is covered on the cybersecurity service.
No. We are not certified partners of the ERP vendors; we build flows from the access and documentation the client holds. The quality of an integration is judged by its contract, logging and cutover plan, not by a partner badge.
Last updated: 2026-09-08
Related services: e-shop development with ERP integration · the web app that calls the API