If you have ever written a script that pulls data from an API, transforms it, and pushes it somewhere else, you have already built an API-to-something pipeline. The question is not whether you can do it — the question is whether it will still be running in six months.

Most automation failures I see are not code failures. They are architecture failures. The script worked on day one because the API was stable, the rate limits were generous, and the data schema matched expectations. By month three, the script is throwing 429s, the schema has shifted, and the person who wrote it has moved on to another project.

1. The REST-to-Action Pattern

This is the pattern everyone starts with, and for good reason. A REST API exposes resources through predictable URLs. You GET a resource, inspect the JSON, extract what you need, and trigger an action. It is simple, well-documented, and universally supported.

The canonical form looks like this:

Trigger Event → GET /resource/{id} → Inspect Response → Take Action

When to use it

  • The API returns clean, predictable JSON
  • You only need a small subset of the response fields
  • The action is triggered by a discrete event (new order, new post, new review)
  • You can tolerate a small delay between the event and the action

The trap most people fall into

The trap is assuming the API response structure is a contract. It is not. APIs change. Fields get renamed. Nested objects get flattened. Arrays become objects. If your script hardcodes field paths like data.product.name, you are one API update away from a KeyError.

2. The GraphQL Aggregation Pattern

REST APIs make you work for your data. If you need a user's profile, their recent posts, and their follower count, you make three requests. If you need that for 100 users, you make 300 requests. GraphQL fixes this by letting you describe exactly what you need in a single query.

Define Data Requirements → Construct Query → POST to /graphql → Receive Exactly What You Asked For → Process

When to use it

  • You need data from multiple related resources
  • Bandwidth or request count matters (mobile, serverless, high-frequency)
  • The API provider offers a GraphQL endpoint with good documentation

3. The Internal API Bridge Pattern

This is the pattern nobody talks about until they need it. You are pulling data from an external API and you want to process it before it hits your main system. But the external data is messy. The Internal API Bridge pattern solves this by inserting your own API between the external source and your consumer.

4. The Partner API Handshake Pattern

Some APIs are not public. They are partner APIs, accessible only through OAuth2, mutual TLS, or signed requests. The Partner API Handshake pattern is about managing the authentication lifecycle, not just the request. It is not enough to get a token. You need to refresh it before it expires.

5. The SOAP Legacy Wrapper Pattern

SOAP is not dead. It is just hiding in enterprise systems. The SOAP Legacy Wrapper pattern is about modernising the interface without modernising the backend. You build a thin wrapper that speaks SOAP to the legacy system and exposes a clean, modern interface to your automation scripts.