How much engineering time does a Norwegian government API bridge save?
Our published planning bands are 40 to 120 hours for the one-off credential setup, 30 to 80 hours for each registry you integrate, and around 4 hours a month of upkeep per integration. They assume a competent team building something production-grade, with retries, error handling and tests, and they assume the calendar time for certificate issuance and terms-of-use approval runs in parallel rather than adding to the total. These are estimate bands for planning, not measurements, and the recurring column is the one that matters more than it first looks.
What is the one-off setup cost?
Our planning band for standing up Maskinporten plus the System User delegation handshake is 40 to 120 hours. That covers obtaining and installing an enterprise certificate, generating and uploading a keypair, implementing the signed client assertion, registering the system, and building the delegation flow you walk customers through. It assumes you are building this to production standard rather than to a demo, which is most of the difference between the two ends of the range.
On top of that, each register you integrate has its own band of 30 to 80 hours. That assumes authentication is already solved by the setup work above, and it covers schema mapping, retries, error handling and a test suite worth having. A project touching three registers is therefore looking at the setup band plus three of the per-register bands, which is where a two-week estimate quietly turns into a quarter.
The range is wide because its widest input is not technical. Certificate issuance and terms-of-use approval move on other organisations' calendars, so two equally competent teams can land at opposite ends for reasons neither controls. We would rather publish a range with the assumptions attached than a single number that looks authoritative and is not.
| Task | Self-built | Through a broker | Assumption |
|---|---|---|---|
| Credential setup | 40 to 120 hours, once. | None. The certificate and client belong to the broker. | Production standard, not a demo. Procurement calendar time runs in parallel. |
| Each registry integrated | 30 to 80 hours each. | One HTTP client against one normalised schema. | Authentication already solved. Includes schema mapping, retries, error handling and tests. |
| Delegation handling | Part of the setup band, then ongoing. | Reduced, not removed. The customer still grants it. | Only the customer can grant authority over its own affairs. |
| Ongoing upkeep | Around 4 hours a month per integration. | Absorbed on the broker's side. | A starting assumption. Real load varies with how many registers you touch. |
| Certificate and key rotation | A recurring calendar item for the life of the integration. | None on your side. | Certificates expire. Rotation is scheduled work, not an incident. |
What is the recurring maintenance cost?
Our starting assumption is around 4 hours a month per integration, and it is the number worth arguing about because it is the one that compounds. A first-build comparison flatters building it yourself: the setup cost is paid once and remembered, while the upkeep is paid forever and forgotten. Over three years the recurring column is usually larger than the build column, and nobody notices because it arrives as scattered small tasks rather than as a project.
What is in it: certificate renewal and key rotation on a schedule, upstream schema changes that break your parsing, delegation states that change without warning, and the general drift of code nobody has read since it shipped. If you run per-client delegations across a customer base, that last category scales with customers rather than with registers, which is a different growth curve than the build estimate suggested.
What is the cost of a breaking change upstream?
Unbudgeted, which is the whole problem with it. A field renamed in a register response is a small fix, but it arrives unannounced, it lands on whoever is on call rather than on whoever planned the sprint, and it is discovered by a customer rather than by a test. The engineering hours are rarely the expensive part; the interrupt and the incident are.
The structural answer is to put the volatile part behind a versioned contract so upstream changes hit an adapter layer rather than your application code. That is worth doing whether you build or broker, and the future-proofing guide covers how to draw that boundary.
For your own numbers rather than ours, the calculator on the direct integration comparison page takes your hourly rate and endpoint count and prints every assumption next to the result. And the zero-auth comparison endpoint returns the same head-to-head as structured data, deliberately qualitative: its earlier static success-rate and latency figures were removed because they could not be substantiated, which is the same standard this page holds itself to.
Make the first call
The comparison endpoint needs no key. Read its methodology field before its dimensions: it states how the comparison was produced, which is the part that tells you how much weight to put on it.
# Zero-auth: the structured comparison, with its own methodology field.
curl -s https://www.apier.no/api/v1/comparison/direct-integration// The comparison is qualitative on purpose: it carries no
// unverifiable success-rate or latency numbers.
const res = await fetch(
"https://www.apier.no/api/v1/comparison/direct-integration",
);
const { data } = await res.json();
console.log(data.methodology, data.source, data.last_updated);
for (const dimension of data.dimensions) {
console.log(dimension);
}Frequently asked questions
- How many engineering hours does a direct integration take?
- Our published planning bands are 40 to 120 hours for the one-off credential setup and 30 to 80 hours per registry integrated, with around 4 hours a month of upkeep as a starting assumption. Those are coarse estimate bands rather than measurements, and they assume a competent team building something production-grade with retries, error handling and tests.
- Why is the setup range so wide?
- Because the widest input is not technical. Certificate issuance and terms-of-use approval run on other organisations' calendars, so two teams of identical skill can land at opposite ends of the range for reasons neither controls. A narrower number would be a more precise-looking guess, not a better one.
- What does the recurring cost actually consist of?
- Certificate renewal and key rotation, upstream schema changes that break your parsing, delegation states that change without notice, and the ordinary drift of an integration nobody has looked at in six months. None of it is visible in a first-build estimate, which is why comparisons made at project start tend to flatter building it yourself.
- Can you give me a price comparison?
- Not from this page, and deliberately so. Money needs an hourly rate we do not have, and a fee we would have to attribute to somebody else. The calculator on the direct-integration comparison page takes your own rate and endpoint count and does the arithmetic with every assumption printed next to the result.
- Are these numbers measured?
- No. They are estimate bands for planning, and we label them that way rather than presenting them as telemetry. The machine-readable comparison endpoint takes the same posture: it returns qualitative dimensions and a methodology field, and it had its earlier static success-rate and latency numbers removed precisely because they could not be substantiated.