WPGetAPI PRO

The nine hundred pound quote for twenty lines of code

It is the situation that makes this plugin exist, and it happens to everybody sooner or later.

You need to show something on your site that lives somewhere else. The shipment status your carrier holds. The free slots your booking system knows about. The prices your supplier publishes. The listing from your management software.

Technically it is simple: ask a programming interface for a value and print it. But in WordPress that means writing code in the theme, and that is why it ends up as a commission to a developer, with its quote, its lead time and the problem that in two years nobody knows where that piece of code is or why it stopped working.

WPGetAPI does it from the admin: you configure the connection, and the data appears on the site through a shortcode.

What it does

• Connects WordPress with external programming interfaces, with no code.
• Fetches data and also sends it, in both directions.
• Displays the result with a shortcode or a template tag.
• Gets configured from the admin, so the connection stays documented and visible rather than hidden in a file.

The mistake that sinks the site: calling on every visit

It is the most frequent fault with this kind of tool and worth understanding before publishing anything.

If the page calls the external service every time somebody opens it, your site becomes as slow as that service. And you do not control its speed: the day their server takes three seconds, your page takes three seconds. The day it goes down, your page goes down with it.

There is a second, worse consequence: almost every service limits the number of calls per hour or per day. A page with a little traffic exhausts that limit in a morning, and then the service stops answering, sometimes for hours and sometimes by cutting off your account.

The solution is always the same: cache the response. Request the data once every fifteen minutes, or every hour, and serve every visitor that stored copy. For a price list or general availability that is more than enough. For something that has to be current to the second, like a shipment status, the right approach is requesting it only when the visitor asks, not on page load.

Two more things before building it

Keys do not go in the content. An API key written inside a post or a template ends up, sooner or later, in a backup somebody downloads or in a repository. They belong in the plugin's configuration, which is where the admin protects them.

Decide what shows when it fails. Because it will fail at some point. A discreet "not available right now" message is infinitely better than a red error or, worse, an empty section that looks like a fault on your site.

Requirements

It needs WordPress and credentials for whatever service you connect to. Worth having their documentation to hand, because each interface has its own way of authenticating and returning data.

Alternatives in the catalogue

If what you want is the opposite direction, WordPress notifying an external service when something happens (an order gets placed, a user registers), that is WP Webhooks. The two pieces complement each other and plenty of projects end up with both.

If what you are after is chaining actions between plugins without leaving WordPress, that is different territory: Uncanny Automator and AutomatorWP connect what you already have installed to each other, without touching external interfaces.

And if your integration is specific and already exists ready-made, the specific plugin almost always works out better than building it by hand: Odoo for WooCommerce for the management system, or Woomelly and WP-Lister for marketplaces. A general tool is the answer when there is no specific one.

Frequently asked questions

Is programming needed?
No. The connection gets configured from the admin and the data appears through a shortcode.

Can it send data as well as fetch it?
Yes, it works in both directions.

Will it slow my site down?
If you call on every visit, yes. With the response cached, no.

What happens if the external service goes down?
Worth deciding beforehand what gets shown, so it does not look like a fault on your site.

Where do I store the key?
In the plugin's configuration, never inside a post or a template.

And call limits?
Almost every service has them. Caching is what stops you exhausting them in a morning.