API integration
API integration services: a named payload between two systems.
You receive a working link between two systems you already use. A number, an order or a payment moves from one to the other, and you can see what happens when the other side does not answer. The diagram on this page is an example of that link. It does not join every API on the internet.
- The diagram is a specimen, not a live call
- A secret is not printed on the page
- The failure rule is written before the first run
Specimen
Client
North Yard shop
API
The named pipe
Server
The books
Request
Response
Before the first call
Six things an API integration has to be able to say
A logo on a slide is not a connection. If any line below is still “we will see”, the pipe is not ready. The quotation names them. A plugin list does not.
The two ends
The system that asks, and the system that answers. Both are named, including the one you already pay for. “The internet” is not an end.
The payload
The fields that travel. An invoice number, a status, a name. Not “the customer record” as a feeling. If a field is missing, the call is the wrong shape.
The direction
One way, or both. A shop may ask the books for a status. The books may also need to hear that the shop took an order. Those are two calls, even when people say “the integration”.
How often
When a person clicks, or on a clock, or when the other side pushes. “Real time” is a phrase. The brief says the actual moment.
The failure
Retry, stop, or show the last good answer. A green tick while the other side is down is a lie. The rule is chosen before the first run, not after the first angry morning.
The record of the run
Enough to see that the call left, and what came back, or that it did not. Exportable. Not a secret log inside a vendor you cannot leave.
One call, written out
A specimen request, and the answer it expects
North Yard already has a shop screen. The books already have the invoice. Someone still copies NY-1042 from one into the other. The slip below is the shape of that copy. It is not a connection we are running, and NY-1042 is not a real invoice.
Specimen call
Not live- Asks
- North Yard shop
- Carries
- Invoice number NY-1042
- Answers
- The books
- Expected
- Reserved, not shipped
Where the pipe lives
Three ways a connection can exist. Building is only one.
Some businesses already pay for a connector between these two systems. Some need one field that the connector does not carry. Some need the pipe built, because neither side will speak unless someone writes the call. The first note says which.
-
01
Keep the connector
You already pay for a join between these two. The brief may be the field it drops, or the failure it hides. A new pipe would copy a road you already have.
-
02
One missing field
The connector runs. The status people need is not on it. The work is that field, the name it has on each side, and what to show when it is empty.
-
03
Build the pipe
Neither side has a join you can trust. Then the call is the product. The quotation names the payload, the direction, the failure, and where the secret lives.
Indicative scope
Three integration briefs. The quotation is the only price.
A public rate would ignore which two systems you already pay for, and whether one field is the whole job. These shapes help you brief. They are not a menu of API licences.
One call
One payload, one direction
One system asks. One system answers. The failure rule is included, because a call without it is a demo.
Start with one callThe pipe
The usual brief
Both directions when the work needs them, the fields on each side, the failure, and a record of the run. Secrets stay where the quotation says.
Brief this scopePipe and clock
After the first call is real
A schedule, or a push from the other side, added after the first call has returned a real answer. Quoted then, not before.
Brief this scopeBefore a call is named
Questions that change the payload if the answer changes
Will you connect any API we name?
No. The quotation names the two systems and the payload. If the other side has no documented way in, or the way in does not carry the field you need, we say so before the build. A list of logos is not a scope.
Is an integration the same as automation?
No. Automation is a step a person repeats between tools you already use. An integration is the payload those systems exchange, including the failure. You may need both. The first note says which one is the work.
Do you print the other system’s key on a page?
No. A key, token, or password stays in the place the quotation names. It is not written into the page a customer can open, and it is not pasted into a chat as the way to “just make it work”. The studio is in India. The primary market is the UAE and the Gulf.
What if the other side is down?
The failure rule runs. Retry, stop, or show the last good answer. The screen does not show success for a call that did not return. That choice is in the quotation, because the morning after a missed night is when people notice the two systems no longer match.
Does this have to be WordPress?
No. WordPress is one possible end, when the brief is a WordPress site. We do not start from a plugin catalogue. This website is PHP, MySQL and HTML. A client project may use another stack when the quotation says the payload needs it.
Can the screen around the call be Arabic or Hindi?
Yes, when the brief asks. The payload can stay in the language the other system already uses. The screen a person reads can be English, Arabic with a right-to-left layout, and Hindi. Those labels are checked before the first real call.
Bring the two systems, not a page of logos
What asks, what answers, and which field has to survive the trip is enough to start. You get a written note: this call, this failure, this place for the secret — or a recommendation to keep the connector you already pay for.
