ChatGPT API integration
The prototype works in an afternoon. The production version is different software: output your code can parse, a bill you can predict, tests that catch a bad answer before your customers do, and a plan for the morning the service is slow.
01Capabilities
Four features teams ship first, and what each costs to run
This is the plumbing page: how an OpenAI-backed feature gets built, tested and operated inside a real product, which is AI integration work. Two of the products running on these models are our own. Snaplore is a revenue-generating AI product with active users that unicrew owns and runs, built on GPT models, Whisper and AssemblyAI. Talkmetry is a revenue-generating call-intelligence product for HubSpot that unicrew owns and runs, built on GPT models and AssemblyAI.
- Extraction
Messy input turned into fields
Invoices, statements, tickets and email, arriving as whatever the sender felt like sending, coming out as data your systems accept. Common in accounting platforms. The cost here is small per item and large in total, because every item goes through.
- Answers
A helper that answers from your own content
The interesting part is not the model. It is what gets found and handed to it: how documents are split, how they are ranked, how fresh they are, and what happens when the answer genuinely is not in the pile.
- Actions
The model calling your systems, with a brake
It picks which of your functions to run. The safeguards are dull and non-negotiable: credentials scoped to the smallest thing that works, a dry run for anything destructive, and a person confirming before money moves.
- Volume
Backlogs worked through overnight
Sorting and enriching queues where nobody is waiting for an answer, as in e-commerce catalogue work. Nothing is urgent, so the whole job can be batched, cached and counted per item, which is where the cost per item becomes controllable.
02Fit
Where the bill goes, and when to stop paying it
The OpenAI API is a sensible default for a first production feature: the tooling is broad, the documentation is good, and most of the surrounding ecosystem assumes it. What it is not is automatically the right model for your task, and switching later is only cheap if the integration was built for it. Four of the six rows below end somewhere other than a project with us on this API.
| Your situation | What we recommend |
|---|---|
| A first production feature, a mainstream task, and you want the broadest tooling | Start hereBuild it behind an interface of your own, so the model stays a setting you change rather than a rewrite you schedule. |
| Long documents and a long list of rules that all have to hold | Compare firstRun the same test set against Claude. On this class of work it frequently changes the answer, and it is a day of work to find out. |
| The input arrives as photographs, scans or video | Different pageGemini reads those directly, which removes a whole conversion stage and the errors that stage introduces. |
| A dozen support tickets a day, handled today by one person | Not yetA template and a saved reply beat any model at that volume and cost nothing to run. Come back when the queue is thousands a week. |
| Millions of near-identical calls, and the bill decides whether the feature exists | Stop paying per wordA cheaper reasoning model, see DeepSeek, or one small model trained for the single job, see PyTorch. |
| The bill is climbing and nobody has read the requests yet | Measure before switchingMost runaway bills are retries on a failing call and an entire document pasted into every request. Changing provider hides that instead of fixing it. |
Scope
What we own on this work is the test set that proves the feature still works after a prompt or model change, the spending ceiling and what the product does when it is reached, the fallback when the service slows, the boundary around your data including what is removed before anything leaves, and a pinned version so a provider update is a decision rather than an incident. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system. Where the honest answer is that the feature is not worth running, you get that answer.
03Delivery
From a working prototype to something you can leave running
Four steps, and the first is not optional. Without it there is no way to tell whether a change to the prompt made the feature better or merely different.
- Write the test set before the promptTwenty to fifty real examples with the output you would accept, taken from your own data rather than invented. It is an afternoon of work and it makes every decision after it measurable.
- Build the smallest prompt that passes, then stopLong elaborate instructions are usually a symptom of a retrieval problem. Every extra sentence is something that can contradict another sentence on an input nobody thought to test.
- Wrap it for the real worldSchema checks on the reply, retries that back off, timeouts, a hard spending ceiling per request and per day, caching for text that repeats, and a second provider configured behind the same interface.
- Log it, read the failures, run the tests againSampled inputs and outputs kept under a retention rule, a weekly look at what went wrong, and the whole test set re-run on every prompt or model change. This is where AI QA and evaluation stops being optional.
04Stack
What else ends up in the same codebase
The pieces that arrive with an OpenAI-backed feature, each with its own page if that is the decision you are actually making.
05Questions
Asked once the first invoice arrives
Six that come up in the second month rather than the first, answered the way we would answer them live.
Yes, and on this work it is often the fastest route, because your people know what a correct answer looks like. What we will not do is add a model call and walk away from its behaviour, since an untested feature of this kind is a liability rather than a release. An architect outside the delivery team reviews the design, and behaviour is covered by our AI QA and evaluation practice. Capacity is managed teams.
Count the cost per request from day one, so you see it per feature instead of as one invoice. After that it is caching text that repeats, sending the easy cases to a cheaper model, batching anything nobody is waiting for, and a hard ceiling that degrades the feature rather than the budget. Most runaway bills we see are retries on a failing call and a whole document pasted into every request.
Start with the terms rather than the folklore, because the API terms are not the consumer product terms, and stricter retention arrangements exist for some cases. That still leaves your own obligations. We strip identifiers the task does not need before the call, hold request logs under the same retention rule as everything else, and write down what leaves your estate. Where nothing may leave, that is a self-hosted model, not a clause.
Rarely, and almost never first. A switch is a project with no visible outcome, and it moves the same spending pattern to a different invoice. Read the requests first: the saving is usually in what you send, how often you retry, and which cases needed a frontier model at all. If a switch still looks right after that, build behind an interface so the next one costs a configuration change.
A scoping call with an engineer. If you have a prototype, send it with the inputs where it fails, because failures are far more informative than successes. You get back a written view on the testing, the cost profile and the integration design, plus a straight answer on whether another provider suits the task better. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, offered once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate depends on the seniority mix, so it is quoted rather than listed.
Prototype works, and the invoice is climbing?
Send us the prototype, the inputs it gets wrong, and last month's bill. You will get an engineer's read on the tests it needs, where the money is going, and what to do on the morning the service is slow.