API integrations
Important information and actions sit in products that do not naturally share them. PrimeLabs builds the application layer that exchanges the right data and triggers the right action, so people stop copying it by hand. A reliable integration has a contract, a failure path, a state and a history. It is not a promise that every product connects at once.
A defined way for one system to ask another for data, or to request a change. The other system decides what it will allow.
The other system calls you when something has happened, instead of you asking on a timer.
Take information in. The source record is unchanged.
Change a record somewhere else. That is the step with consequences.
A named thing that happened: a payment, an upload, a status change. The event is not itself the write.
Keeping an agreed set of fields current. It is not a licence to mirror every column in both directions.
Turning one system’s shape of a customer, a date or an amount into the shape the other system expects.
Reading a customer, an invoice or a payment is how an application stays informed. Proposing a change is the prepared payload: the fields, the identifiers, the checks that already passed. Performing the write is the call that alters the other system.
Not every write needs a person. A low-risk update that the contract allows can run once the checks pass. A write with business impact deserves more care: validation, a precondition that must still be true, approval where the cost of a mistake is high, a repeat that does not create a second record, and a history of what was sent. Doing the step twice must not produce two payments. That is the practical test. Engineers call the property idempotency.
The example on this page holds an accounting write for that reason. The payment event has arrived. The invoice matches. The write has not been sent.
This hub is an example, not a client integration. Select an event. The accounting payment can be approved here. The message stays on this page.
Example interface. Not a client project.
Integration hub · CRM, accounting, payments, email, document storage
Success
Success
Ready for review
Success
Retry scheduled
An integration needs a plain answer to who owns the record. If two products can both change the same phone number, the next sync becomes an argument. Ambiguous two-way ownership is how stale and duplicate records appear.
A workable split is ordinary: the CRM owns the customer contact, the accounting system owns the invoice, and the PrimeLabs application coordinates the process that uses both. It may store a copy for the screen the staff or the customer sees. It does not become a second ledger, or a second CRM, unless that was the decision.
That coordination is often what an internal business application or a customer portal needs. The portal can show an invoice status it does not own. The internal tool can show a customer it does not own. The integration is how those reads, and any later write, stay honest.
A customer id in one product is an account id in another. Status words differ. Dates arrive in more than one format. Money may be dollars in one payload and cents in the next. Addresses are one line or five. Product codes and user identifiers diverge as soon as two vendors are involved.
Mapping is the explicit table of those differences, plus the checks that reject a value the destination cannot store. Without it, a successful HTTP call can still write the wrong record. Feasibility depends on the source system’s API, its permissions, its rate limits and its data model. Naming a product here is not a claim that it is already connected.
A payment succeeded. A document was uploaded. A customer was updated. A booking changed. An invoice was marked paid. An application was approved. Those are useful events. Receiving one means the integration can wake up, check the signature, find the internal record, and decide what is allowed next.
The decision can be “record this and stop”, “queue a later step”, or “prepare a write and wait”. Blindly posting to a second system because a webhook arrived is how a duplicate or a forged event becomes a real change. Where the next step is a long run with retries and a person, that belongs with workflow automation. Where the event is a file, the reading of that file is a document workflow, and only an approved result should be written downstream.
Providers time out, limit bursts, and have outages. A retry is right for a temporary failure, with a limit, and with the same identity so a second attempt does not create a second payment or customer. A rate limit is a reason to slow down, not to hammer the endpoint.
Duplicate delivery is normal. Webhooks are often sent more than once. The handler has to recognise an event it has already accepted. When retries are exhausted, or the payload is rejected for a reason that will not change, the event waits for a person. Some teams call that a dead letter. The useful version is a row someone can open, with the error and the record it belongs to. The history of attempts stays either way.
A useful history answers what happened, when, to which record, which provider, whether it succeeded, whether it was tried again, and whether a person still needs to act. That is the screen in the example: a morning of events, one write held, one retry scheduled.
Without that record, a failed status update looks like the CRM “just didn’t update”, and the only investigation is someone’s memory of a script. Observability here is not a separate monitoring product. It is the integration keeping its own account of each exchange.
Cloudflare can host this. It is not the subject of the page. Which services belong, and which do not, is on Cloudflare application development.
API keys and tokens are secrets on the Worker, not in the browser and not in the page. Each credential should have the smallest permission that the exchange needs. A key that can read customers should not also be able to refund payments. Webhooks are checked with the provider’s signature before the payload is trusted.
Tokens get rotated. The application should tolerate that rotation without a redeploy being the only plan. Write permission is separate from read permission, and the audit trail shows who or what approved a write. The web application around the integration is what enforces that boundary.
Providers impose request quotas, burst limits, operations they simply do not offer, data that is briefly stale, pagination, outages, and scopes that do not include the field you wanted. PrimeLabs designs the exchange around those constraints. Polling harder does not create an endpoint the vendor did not publish.
Not every exchange should be instant. An immediate event suits a payment or an approval. A queue suits a burst. A schedule suits a nightly reconciliation. A person can refresh one record when they are looking at it. The right model is the one the business actually needs, not the fastest one that can be drawn.
Inside an integration, a model can classify an unstructured note, suggest a match between two descriptions of the same customer, summarise why a call failed, or draft the reconciliation a person will confirm. It does not hold credentials, invent identifiers, choose a financial write, skip validation, or replace the provider’s contract.
Identifiers, amounts and allowed operations stay in ordinary code. How that boundary is drawn more generally is AI application development.
A useful first note names the two systems, the field that is copied, which one owns it, whether the change is a read or a write, and what should happen when the call fails. There is no account on this website.
No. Each connection depends on that product’s API, permissions, limits and data model. The first version is usually one exchange that is already being retyped.
No. A write waits when the impact justifies it, or when a check has not passed. A read does not wait for approval of a change that is not being made.
Only if that update is in the contract and the checks pass. Receiving the event is not the same as being allowed to write.