Website forms into the client’s CRM
Enquiries, sign-ups and quote requests arrive in the CRM with the right fields, owner and tags. Existing contacts are matched and updated instead of duplicated.
API integration development for agencies.
Connections that fail loudly, not silently.
When a client brief says “and it should sync with our CRM”, I build that part under your brand. You keep the client; I build the integration, document it and hand it over so your team can run it. Feasibility review: €490, fixed price.
Milan Danilovic, founder- White label under your brand
- Validation, retries and logging by default
- Documented for handover
- Based in Serbia · European time zones
Typical agency briefs
The site is designed.
Now it has to talk to everything else.
Most integration work starts as one line in a website brief. It is also where projects quietly go over budget, because the other system’s API decides how hard the job really is. These are the most common shapes it takes.
Shop orders and stock in sync with an ERP or inventory system
Orders flow out to the system that fulfils them, and stock levels and prices flow back to the shop, so nobody sells what is not on the shelf.
Payment and booking providers
Checkouts, deposits, appointments and cancellations go through the provider’s API. The site updates its own records when the provider confirms, not when the visitor clicks.
Data moving between the client’s SaaS tools
Scheduled or event-driven syncs between tools that do not talk to each other, replacing the spreadsheet export someone does by hand every Friday.
Webhooks in and out
Incoming events are checked, acknowledged quickly and processed in the background. Outgoing events are sent with retries, so a short outage on the other side does not lose data.
How I build them
Assume the other side
will fail sometimes.
APIs time out, change their responses and send the same event twice. An integration that only works on a good day becomes a support ticket for your agency. These are the defaults I build in, not extras on a quote.
Validate everything at the edge.
Every payload is checked against a schema before it touches the client’s data. Bad input is rejected with a clear reason instead of being half saved.
Retry what can be retried.
Timeouts and rate-limit responses are retried with a growing delay. Errors that will not fix themselves, like a missing field or revoked access, stop and get flagged instead of looping forever.
Make repeats harmless.
Webhooks arrive twice and jobs get re-run. Each operation carries a key, so a repeat updates the same record instead of creating a second order or contact.
Show failures where people will see them.
Each item has an explicit state: pending, done or failed. Failed items are listed with the reason and can be re-run, so nobody learns about a problem from an annoyed customer.
Log enough to answer “what happened?”
Logs record what was sent, what came back and when. They leave out secrets and keep personal data to what is needed to trace a problem.
Document it for the next person.
Setup, environment variables, field mapping, failure handling and how to re-run a failed item are written down, so your team can operate it without calling me.
What your agency gets
An integration your team
can run without me.
- A field mapping agreed with you before the build
- The integration code in an agreed repository
- Tests for the mapping and the failure paths
- Logs, a failed-items view and an agreed alert route
- Setup and operations documentation
- A handover walkthrough with your team
I work in TypeScript and Node.js, with NestJS where a larger service is needed, and with SQL or document databases depending on what the integration has to store. Once the project is paid, the code written for it belongs to your agency, ready to transfer to your client.
Pricing
Start with the API,
not with a guess.
Feasibility review, €490 fixed
I read the API documentation, test access with sandbox credentials, check rate limits and data quality, and send a written plan, risks and an estimate you can quote your client from.
Engineering pilot, from €2,900
One well-defined integration, built and tested against acceptance criteria, can be scoped as a pilot. Smaller changes run at the day rate of €450.
Typical project start: 1–2 weeks after agreement, subject to availability. Prices in EUR, excluding VAT.
See all partnership pricesProof of capability
The same habits,
in software you can inspect.
Most of my client integrations are under NDA. Here is how my own products handle third-party data, background work and failure, plus systems I built in employment. You can open each one and see the engineering.
SignageStack: third-party data behind a clean boundary
Display apps bring in Google Calendar, Sheets, Slides and Canva designs. The Calendar connector keeps the OAuth connection behind the API and turns events into one shared format, so screens receive display data, never credentials, and an integration change does not touch the layout.
Inside SignageStackCultureFitr: background work with honest states
Slow AI report generation runs as background jobs. Each report is pending, generating, ready or failed, interrupted work is queued again, and the AI provider sits behind its own interface, with a mock for development.
Inside CultureFitrMorgenlese: nothing ships without passing checks
Hand-written and AI-generated stories go through the same validation schema before publication. The same principle applies to data arriving from someone else’s API.
Inside MorgenleseEmployment: repeated submissions and partial failures
In an enterprise workflow modernization I worked on, processing had explicit states for completed, partial and failed work, and transactional submission logic handled concurrent updates and repeated submissions.
Selected engineering experiencePractical questions
Integration questions agencies ask.
How do you handle API rate limits?
I read the provider’s limits before estimating, because they shape the design. Bulk syncs are batched and paced, calls are queued instead of fired all at once, and rate-limit responses are retried after the wait the API asks for. If the client’s volume cannot fit their plan’s limits, you hear that in the feasibility review, not after launch.
What happens when the third-party API changes?
I pin the API version where the provider allows it, keep the field mapping in one place and validate responses, so an unexpected change fails visibly instead of writing bad data. Moving to a new API version is maintenance work, quoted at the day rate or covered by a support agreement.
How is the integration monitored?
At minimum: logs, a list of failed items with the reason, and an alert to an agreed email address or channel when something keeps failing. If the client already uses a monitoring or error-tracking service, I report into that. Round-the-clock on-call is not included by default.
Who owns the API keys and credentials?
The client, or your agency if that is how your contract works. Accounts, API keys and OAuth apps are created in their name and I get access for the build. Secrets live in the hosting environment’s secret storage, never in the repository, and my access is removed or keys are rotated at handover.
What if the API is badly documented?
That is the biggest source of estimate risk, which is why the feasibility review exists. I test the real endpoints with sandbox or test credentials before giving you a fixed quote.
Where does the integration run?
Usually as a small service or scheduled job on the client’s existing hosting or on a cloud platform we agree. For WordPress or Webflow sites it normally runs beside the site rather than inside it, so it can queue, retry and log properly.
Start with one connection
Which systems does
your client need connected?
Name the systems, what should move between them and how often. Links to API documentation help. Please leave out credentials and client data. I’ll come back on feasibility and a sensible first scope.
Describe the integration