Integration Engineer Job Description Template 2026

Last updated: August 30, 2026

By Robert Ardell, Co-Founder and Strategic Advisor, KORE1

An integration engineer job description has to name the systems on both ends, the platform in the middle, the integration pattern, and who gets paged when the pipe breaks. Leave any of the four out and the title does the work of five different jobs at once, which is exactly why the resumes come back wrong. Published US pay for the role runs from roughly $65,000 to $173,000 depending on which of those jobs you actually meant.

The design passed every functional test it was given. Every one.

A mid-market pharma manufacturer had a serialization integration scoped, reviewed, and close to signed. Data mapped correctly in both directions. Error handling was thought through. The reviewers on both sides signed off, because the thing they were checking was whether the right values landed in the right fields, and they did.

Nobody had costed the call volume. Designed at the unit level, the way the spec was written, it would have made roughly 1,350,000 API calls a year against a licensed allowance of 130,000. Ten times over. Not a rounding error, not a tuning problem, and not something you discover gracefully in month four of production.

The fix was one design decision. Batch at the transaction level instead of the unit level, around 141 documents a month at four to six calls each, and the same integration fits inside a quarter of the allowance. Same data. Same systems. A different answer to a question nobody on that project had been assigned to ask.

That question is the job. It is not “connecting systems.” It also does not appear in a single one of the integration engineer templates currently ranking on page one. Not one.

My angle, so you can price it into everything below. KORE1 runs an integration engineer staffing desk and has been placing API and integration architects since 2005, and a page arguing that integration deserves a named owner is a page arguing for work that lands on my desk. There is a section further down about hiring nobody. It is short, it is real, and I would read it second.

Five Different Jobs Answer to This Title

Start here. Everything downstream inherits this decision.

“Integration engineer” is one of the most overloaded titles in enterprise technology. Five separate roles wear it, they share maybe a third of their skills, and at the extremes they price about $90,000 apart. Most reqs describe one and interview for another. Then the offer gets declined. Everyone blames the market.

The iPaaS developer lives inside a platform. Boomi, MuleSoft Anypoint, Workato, SnapLogic, Azure Logic Apps, Celigo. They build the flows, manage environment promotion, and know where that platform lies to you. Every platform lies somewhere. Someone strong in Boomi is not automatically strong in MuleSoft, and pretending otherwise costs you a quarter.

Then there is the API engineer, whose work sits one layer up. Contract design, versioning strategy, the gateway in front of everything, OAuth scopes, rate limiting, and the deeply unglamorous discipline of not breaking a consumer you have never met. Apigee, Kong, AWS API Gateway. This person argues about pagination and is right to.

Third seat is streaming. Kafka, Confluent, EventBridge, Pub/Sub. Schema registry governance, partition keys, consumer lag, replay semantics, and the 3 a.m. question of whether a message was processed twice or zero times. Different mental model entirely.

The fourth is enterprise application integration, and it is the one most mid-market companies are actually hiring for without knowing it. NetSuite, Salesforce, Workday, SAP. The pipe is the easy half. The work is the object models on either end of it, plus the platform limits that constrain what you are allowed to do inside them.

Fifth seat is the one nobody warns you about. In aerospace, defense, and medical devices, an integration engineer builds test benches, runs hardware in the loop, and maintains requirements traceability against DO-178C or IEC 62304. Real discipline. Real career. Almost zero overlap with anything above, and a meaningful share of the applications to your generic posting will come from it.

You are allowed to want a hybrid. Plenty of companies genuinely need one person spanning three of these, and that person exists. They are senior. They know the number. They will not apply to a posting written for a coordinator.

Publish the Seam, Not the Skill List

An integration engineer is hired to own a seam. Two systems meet, neither team owns the meeting, and the failures happen in the gap. A candidate cannot evaluate a seam they cannot see. So show it. Show the ugly parts.

Six facts do it. What the source systems are, by name. What the target systems are, by name. The platform in the middle, or an honest “none, it is hand-rolled Python on a cron.” The pattern, meaning nightly batch, scheduled sync, request-response API, or event stream. Volume, and the latency anyone actually expects. Then the last one, which almost nobody publishes and which every serious candidate wants to know: who carries the pager when it breaks at two in the morning.

Write those six into the first paragraph and you have described a real job. “Our order flow moves from Shopify into NetSuite through Celigo, about 900 orders a day, with a Salesforce sync on a fifteen-minute schedule and a two-person on-call rotation.” Four seconds. That is how long a qualified candidate needs to decide whether they can do it.

Compare that to the phrasing every template on the first page of Google recommends. “Design, develop, and maintain integrations between enterprise systems.” True of all five jobs above. Informative about none of them. It filters nobody out. That feels safe. It stops feeling safe around application 180.

Vendor names matter more than people expect. Cloud adoption has not converged the way the marketing suggests. The 2025 Stack Overflow Developer Survey put AWS at 43.3% of developers, Azure at 26.3%, and Google Cloud at 24.6%. Not close. Naming yours is not bragging. It tells a stranger whether their last four years transfer.

The Two Constraints No Template Mentions

Both of these have killed timelines on projects I have watched. Neither appears in a job description anywhere.

The first is the call budget. Every SaaS platform you integrate with meters you, and the meter is a design constraint rather than an operations detail. Salesforce is the clearest example because it publishes the numbers. Per the Salesforce developer documentation, an Enterprise Edition org starts at 100,000 API requests per rolling 24-hour period and scales up with provisioned licenses. It is a soft limit, so you sail past it for a while. Then a system protection threshold engages and calls start returning 403. Always on a bad day.

The pharma example at the top of this page is the same failure with a bigger multiplier. A design that iterates per unit rather than per transaction is not wrong. It is ten times more expensive than the license permits. Nothing subtler than that. The difference between an engineer who catches that in design review and one who catches it in production is most of what you are paying for.

Put it in the posting. One line. “Candidates should be comfortable reasoning about API call budgets and platform governor limits at design time.” Anyone who has been burned by this reads that line and understands you have been burned too.

The second constraint is authentication. It breaks estimates more often than anything else on this list, and not because it is hard. Because it is assumed.

A concrete one. A NetSuite RESTlet will not accept a plain API key, which means an external caller has to present OAuth 1.0 token-based authentication or a signed OAuth 2.0 request. Fair enough. It also means that when a vendor tells you their webhook authenticates with an API key in a header, and it usually does, somebody has to build and host an authenticated relay in between. That is a service. It has an owner, a deployment, a certificate, and a rotation schedule, and it is almost never in anyone’s estimate. It is also the exact question that separates a candidate who has shipped this from one who has read about it.

Two sentences in the requirements section cover both constraints. That is the whole intervention.

What the Band Actually Tracks

Published averages for this title disagree with each other by a wider margin than almost any role we staff. The disagreement is the useful part.

Figures as reported August 2026. Glassdoor and ZipRecruiter report blended pay, Payscale reports base only, which explains part of the gap.

A $37,000 spread between two averages for one job title is not measurement noise. It is five jobs averaged together. Nothing more mysterious than that.

Read the percentiles instead and the shape resolves. The bottom of the Payscale range, around $65,000, is a monitoring and triage seat. Watch the queues. Rerun what failed. Escalate the rest. The middle, roughly $100,000 to $130,000, is a working iPaaS developer building and maintaining flows on one platform they know well. Above that, call it $140,000 to $175,000, you are paying for people who design the estate rather than work inside it. Enterprise application specialists land near the top too. Deep Salesforce, Workday, SAP, or NetSuite object-model knowledge takes years to build and does not transfer sideways, so the few people who have it price accordingly.

For the wider market, the Bureau of Labor Statistics put the median annual wage for software developers at $135,980 in May 2025 and projects 16% employment growth from 2024 to 2034, with about 106,100 annual openings across developers, QA analysts, and testers. Demand for the platform layer specifically is climbing faster than that. Gartner’s market share analysis found the worldwide iPaaS market grew 23.4% to $8.5 billion in 2024, the second fastest-growing segment of the application and infrastructure middleware market.

If you want a sanity check against your own market before the req goes live, our salary benchmark assistant will give you a band for your city and seniority in a couple of minutes. The seat-by-seat breakdown lives in our level-by-level pay bands for the role, and there is a companion walkthrough on scoping the role before you post it.

Integration Engineer Job Description Template

Copy this. Everything in brackets is yours to replace, and the bracketed italic notes are instructions to you, not text for the posting.

Job Title

[Integration Engineer / Senior Integration Engineer / Integration Developer, [Platform]] [Put the platform in the title if you run one. “Integration Engineer, Boomi” outperforms “Integration Engineer” on qualified applications by a wide margin, because it is a search term people actually use.]

About the Role

[Company] is hiring an integration engineer to own the connections between [name your source systems] and [name your target systems]. Our estate runs [Boomi / MuleSoft / Workato / Azure Logic Apps / hand-built services] moving roughly [volume] [orders / records / events] per [day / week], with [pattern: nightly batch, 15-minute scheduled sync, event stream, request-response API]. You will be [the first dedicated integration hire / joining a two-person integration team inside a six-person platform group], reporting to [role].

What You Will Own

• Design and build of integrations between [System A] and [System B], including the error handling and retry logic that decides whether a bad night is a ticket or an incident
• The connection to [ERP / CRM / HCM], meaning the object model, the field mappings, and the platform limits that shape what is possible inside it
• Call budget and governor limit planning at design time. [Leave this in. It is the highest-signal line in the posting.]
• Authentication and credential lifecycle across every endpoint. OAuth token rotation, certificate expiry, and service account hygiene, which is boring right up until the morning it is not
• Monitoring, alerting, and the runbook that lets somebody else triage at 2 a.m. without calling you
• [If applicable: migration from [current state] to [target platform] through [quarter], and ownership of the platform after the implementation partner rolls off]
• Documentation of every interface, its owner, its schedule, and its failure mode. [The undocumented estate is why your last integration person was impossible to replace, and that was a liability rather than a compliment.]

What We Need to See

• [3+] years building production integrations. Not configuring a connector once during an implementation, and not filing tickets about one
• Hands-on depth in at least one of [Boomi / MuleSoft Anypoint / Workato / Azure Logic Apps / Apache Camel / custom services], with the ability to walk through something you built and name the one decision in it you would make differently now
• Working knowledge of [REST / SOAP / GraphQL / file-based EDI / message queues], and a real opinion about when each is the wrong choice
• API authentication beyond a static key. OAuth 2.0 client credentials, token refresh, signed requests, and mutual TLS where it applies
• SQL, or equivalent comfort querying the data behind a failed record instead of guessing
• Judgment about volume. [A candidate who asks what your API allowance is before proposing an architecture has told you most of what you need to know.]
• [If streaming: production Kafka experience covering partitioning, consumer groups, schema evolution, and what you did the first time you had to replay a topic]

Nice to Have

• Second platform exposure, because most estates end up hybrid whether anyone planned it or not
• [Name the ERP or CRM you actually run.] Salesforce governor limits, NetSuite SuiteTalk and RESTlets, Workday EIB and Studio, and SAP BTP are each their own body of knowledge
• Event-driven architecture experience, particularly around idempotency and exactly-once delivery in systems that do not really offer it
• Infrastructure as code, CI/CD for integration artifacts, and environment promotion that is not a person clicking through a UI
• [Industry-specific: HIPAA, PCI DSS, GxP validation, or whatever regulatory frame your data moves inside]

How This Team Works

[Answer what a good candidate is quietly wondering. Is there an on-call rotation, and how often does it actually fire? Who owns the incident when the failure is in a vendor’s API rather than yours? Does this person talk directly to the vendor, or is there an account manager in between? What happens to this job during month-end close or peak season? Six honest sentences here will beat a longer benefits list every time.]

Compensation

[$110,000 to $145,000] base, plus [bonus], [benefits], [remote or hybrid detail]. [Post the range. Several states require it, this candidate pool compares openly, and a published band filters faster than any screening question you could write.]

What Comes Up on the Intake Call

We posted for an integration engineer and half the applicants were aerospace test engineers. Why?

Your posting used a title that means something completely different in defense, aerospace, and medical devices, where an integration engineer runs hardware-in-the-loop test benches and requirements traceability. Both groups are right about their own title. Neither is confused. The fix is naming your software stack in the first line rather than the fifth bullet. “Integration Engineer, Boomi and NetSuite” ends the ambiguity before anyone opens the description. It also cuts total applications by a lot, which is uncomfortable for about a week and correct for the rest of the search.

Our last posting listed eleven tools and we still got the wrong people. What do we cut?

Nine of the eleven are probably noise. A tool list describes a shopping cart, not a job, and candidates read it as a wish list nobody expects them to meet in full. Cut to the estate facts instead. What connects to what, through what, at what volume, and who owns the failure. Keep the two or three tools somebody genuinely has to know on day one and move the rest to a nice-to-have line where they belong. The reason the long list fails is that a license is not an owner. Boomi hands you connectors and a runtime, and it decides none of the things that break, so a posting organized around tools is describing the part that was never the problem. If you are still choosing the platform itself, our guide to hiring a Boomi developer covers that decision.

How do we screen this when nobody on our side can evaluate the answer?

Ask about an integration that failed in production and what they did in the first ten minutes. You will hear the difference without being technical. A real one talks about establishing whether the failure was upstream or downstream, pulling the actual payload, and working out whether a vendor changed something quietly. The other answer stops at “I opened a ticket.” That is the tell. Then ask what they would need to know before proposing an architecture. If API limits and data volume are not in the first three things they say, keep looking.

The rest of the loop, work sample included, sits in the questions we actually ask for this role.

Should this go out as one req or two?

One req covers a stable estate of roughly ten to twenty interfaces at a known volume. Two thresholds break that. On-call is the first, because a rotation of one is not a rotation, and a posting that quietly implies solo pager duty gets read correctly by exactly the candidates you wanted. The second is a migration running alongside the existing estate, which is two jobs on one desk, and the usual answer there is one permanent req plus a contract specialist for the build window rather than a second permanent seat you will not need in a year. Write whichever is true. A req that hides the second job gets found out in week three.

Our security team says naming our stack in a posting is a risk. Are they right?

Partly, and the distinction they are missing is between naming a system and exposing one. Your ERP vendor already publishes your logo as a case study. Your engineering blog names your queue. An attacker learns nothing from “we run NetSuite and Celigo” that a search would not surface in a minute. What genuinely should not go in a posting is version numbers, endpoint hostnames, internal service names, or identity provider configuration, and security is right to hold that line. Name the stack as context, not as a hard requirement. Those are different moves. Listing Boomi so a candidate understands the estate helps you. Making Boomi a screening gate when somebody strong in MuleSoft would be productive in six weeks costs you good people, which is why our guide to hiring an integration engineer argues against requiring the platform even where this page argues for naming it.

Does this seat justify permanent headcount, or should we rent it?

Contract for the build, permanent for the estate. A platform migration, an ERP cutover, or a post-acquisition systems merge each has an end date, and specialists who do that work full-time are worth the premium for a few months. Ongoing ownership does not end, and every time it gets covered on rolling contracts the documentation quietly rots and the knowledge walks out with the last person. There is a third answer. It is real. Fewer than five interfaces, stable, nothing changed this year, and a strong backend developer with 20% of their time allocated is the honest call. We will tell you so on the phone. KORE1 averages 17 days to hire across IT placements and holds a 92% twelve-month retention rate, and neither number helps you if the role should not exist yet.

Before You Hit Publish on the Req

Three questions. If all three answer cleanly, post it.

Does a stranger know which systems they are connecting, by name? Does the posting say what is in the middle, or admit that nothing is? Does it tell them who gets called when it breaks, and how often that has happened lately?

Miss all three and you have written a category rather than a job. The people who could do it keep scrolling. The ones who apply are answering a different job that happens to share a title. Fixing that costs one editing pass and about twenty minutes.

If you would rather not run the search alone, talk to a KORE1 recruiter and we will pressure-test the req before it goes live. Our integration architect staffing desk runs these searches across MuleSoft, Boomi, and event-driven and Kafka estates, and our ERP consultant staffing practice picks it up when the work is really about the application layer rather than the pipe. If the problem is architectural rather than a headcount gap, our playbook on decoupling point-to-point integration covers what to do before you hire anyone, and the IT staffing services hub has the wider picture. If you have already decided to run the search, how we staff integration engineers covers what that engagement looks like.