API and integrations

What this category covers

Four related jobs sit here. Building and testing requests by hand. Documenting an interface so other people can use it. Putting a gateway in front of several services so that keys, rate limits, quotas and versions behave the same way everywhere. Moving data between products that were never designed to talk.

The first three are for teams shipping an API. The fourth is for anyone stitching together tools they bought. Both audiences end up on this shelf, which is why the products look so unlike each other.

Purely visual automation with no code involved belongs in no-code and automation. Alerting on a live service is monitoring.

Clients, and what separates them now

Every client sends a request and shows a response. The differences are further in.

Environment handling comes first: local, staging, production and whatever a colleague runs on a laptop, switching cleanly without anyone editing a URL by hand. Then scripting, so a token can be fetched before a request rather than pasted in each morning. Then test assertions, so a collection becomes something a build server can run.

Collaboration is where opinions divide. Cloud sync is convenient and puts your request history on someone else’s servers. File-based tools keep collections in the repository next to the code, so a change reviews like any other and no workspace walks out with a departing employee.

Ask where secrets live either way. A key written into an exported collection is the standard route into a public repository.

Documentation that does not rot

Handwritten documentation is out of date within a quarter. The only arrangement that survives is generation from a specification that lives with the code and rebuilds when the code merges.

Check three things: whether the product reads your specification format without a conversion step, whether examples can be executed from the page, and whether old versions stay published for the people still using them.

A changelog matters more than design. Consumers need to know what broke and when, and no amount of styling replaces that.

Gateways, and when one is worth it

A single service rarely needs a gateway. The case appears once authentication, rate limits, quotas and versioning have to behave identically across several services.

At that point the questions are: where it runs and how much latency it adds, how limits are defined, and what a caller sees when one is hit, whether keys can be rotated without downtime, and what the logs contain. Anything that terminates traffic becomes an availability risk of its own, so ask what happens when the gateway itself has a bad day.

What the pricing meters

• Seats on clients and documentation products, sometimes free for read-only reviewers.
• Tasks or runs on integration platforms, counted per step rather than per workflow.
• Calls or bandwidth on gateways, with a separate rate for anything cached.
• Retention of run history, which is short on entry plans and short exactly when you need it.
• Connectors, with the premium ones parked one tier above the plan being quoted.

Task pricing deserves arithmetic before signing. A workflow with six steps running every ten minutes is not one task a month, and the number it becomes has surprised plenty of teams. The same shape of surprise across other categories is collected in what pricing pages hide.

What to test

Rebuild one real integration you already run, end to end, including the part where the other side returns an error.

Watch how the tool handles retries, duplicate delivery, a stalled third party and a payload that arrives with a missing field. Well built products let you replay a failed run after fixing the cause. Weaker ones lose it silently and tell you nothing until a customer does.

Then check the exit. Collections, specifications and workflow definitions should be exportable as files you can read. Anything locked inside a workspace is work you will do twice.

Documentation, versioning and keeping consumers

An interface with users is a promise, and most of the difficulty in this category comes from changing one without breaking that promise.

Decide a versioning approach before the first external consumer arrives, since retrofitting one means asking everybody to change at once. Whatever the scheme, publish what changed and when, and give a deprecation period measured in months rather than weeks.

Errors deserve as much attention as successes. A response that says what went wrong, which field caused it and what to do next removes more support requests than any amount of prose.

Then read your own documentation as a newcomer would. The fastest improvement available is usually a working example at the top of the page rather than a reference table.