WordPress API and system integrations
WordPress rarely stands alone. In most of the platforms we build it is the presentation and editorial layer over data that is authoritative somewhere else: a CRM, a member system, an internal platform, a partner’s API. Getting that relationship right is what keeps the website accurate without asking anyone to maintain the same record twice.
- Built against documented APIs, in code we own and can debug
- Caching, rate limits and defined behaviour when the other system is down
- Authentication handled properly: service accounts and token exchange, not credentials in the database
- One authoritative source per piece of data, by design
One system of record, not two copies
The failure mode in integration work is almost never the connection. It is duplication. Data gets copied into WordPress “for performance”, the copy is edited, the two versions diverge, and within a year nobody can say which is correct. The integration then becomes something people work around rather than rely on.
So the first decision in any integration is which system owns each piece of data, and it is written down. WordPress caches what it reads and presents it; it does not quietly become a second source of truth. Where WordPress genuinely is authoritative for something (editorial content, page structure, the things editors create) it writes outward on the same terms.
The second decision is what happens when the other system is unavailable. Every external dependency will be down, slow, rate-limited or returning something unexpected at some point. An integration that works is ordinary; one that degrades predictably is the difference between a platform and a demonstration.
Integrations we have built
The list below is drawn from delivered work rather than from a capability matrix. The pattern generalizes: if a system has a documented API, it can be integrated properly.
Payments
Stripe-based payment flows built into custom commerce and subscription features, without a general-purpose e-commerce plugin stack behind them.
Calendars and scheduling
Google Calendar integration and full calendar interfaces for member and community platforms, including recurring events and controlled visibility.
Maps and location services
Google Maps integrations for directories, service areas and location finders, built to load without degrading page performance or accessibility.
External data feeds
Third-party data pulled on a schedule through WP-Cron and presented in the interface. Weather and conditions data in a members’ portal is one delivered example.
Search, analytics and consent
Google Search Console service-account integrations, tag management, and consent management platforms wired so that analytics respects the consent state rather than ignoring it.
Calculators and tools
Rate, payment and eligibility calculators built against live data rather than hard-coded tables, so the numbers change when the source does.
Document generation
PDF documents produced from live site data at request time, such as invoices, confirmations and records, rather than maintained by hand or assembled outside the platform.
Need WordPress to talk to something else?
Tell us which systems are involved, which one owns the data, and what has to happen when one of them is unavailable. That conversation usually determines the whole shape of the build.
The parts that are not the API call
Documented APIs over plugin stacks
An off-the-shelf connector per system becomes an unmaintainable dependency graph and a security surface. We write against the published API in code that can be read, tested and debugged.
A caching strategy with invalidation
Decided deliberately per data type: what is cached, for how long, and what clears it, so that a slow upstream service never becomes a slow website.
Failure that is visible and graceful
Errors logged with enough context to diagnose, retries where retrying is safe, and a front end that degrades to something sensible instead of an empty page.
Credentials handled correctly
Service accounts and token exchange, secrets in configuration rather than in the database or the repository, and least-privilege access for every connection.
Scheduled work that can be observed
Synchronization jobs with logging, run history and alerting, so a sync that silently stopped three weeks ago is not discovered by a customer.
Documentation for the next developer
What connects to what, in which direction, how often, with which credentials, and what happens when it fails. Written down as a deliverable.
Integrations we have shipped
A CRM as the system of record. On the M3 Tech platform, broker, office and franchise records are synced from the client’s BOSS CRM over an authenticated API, with the Multi-Prêts and Mortgage Intelligence builds documenting JWT authentication specifically. Rate data is read per province from the same platform rather than maintained by hand, and broker search runs on Google Maps with geocoding.
Payments and documents. iAmEvolving® uses Stripe PaymentIntents and Subscriptions across two currencies, with invoices generated as PDFs at request time rather than maintained anywhere.
Calendars, weather and consent. Doolittle Lake Club reads Google Calendar through FullCalendar with ICS export, and a weather widget calls OpenWeatherMap behind a two minute cache so a third-party outage cannot slow the page. The M3 brands run Didomi for consent, wired so analytics respects the consent state.
Search Console inside the editor. This site and the iAmEvolving® platform both read the Google Search Console API through a service account, presenting per-page performance to editors where they work instead of in a separate tool.
Frequently asked questions
-
What if the system we need has no API?
Then we say so before it becomes a line in a proposal. The realistic options are a scheduled file exchange, a database-level read where the other system allows it, or building the missing surface if its owner will cooperate. All three are more fragile than an API and cost more to maintain, and you should know that when the budget is set rather than when the sync first fails.
-
What happens when the other system goes down?
It is designed for, because it will happen. Cached data continues to serve, the failure is logged with enough context to diagnose, retries happen where retrying is safe, and the page degrades to something sensible rather than to an error or a blank region. Deciding this per integration is part of the build rather than something added after the first outage.
-
Can WordPress write back into our CRM, or only read?
Both, where the other system’s API allows it. The important decision is not direction but ownership: which system is authoritative for each piece of data. We write that down at the start so WordPress never quietly becomes a second source of truth that then diverges from the first.
-
Do you use connector plugins or services like Zapier?
Rarely, and not as the backbone of a platform. A connector per system becomes a dependency graph nobody can reason about, a recurring cost, and a security surface. We write against the published API in code that can be read, tested, logged and debugged, and that you own.
-
How are credentials handled?
Service accounts and token exchange rather than a user’s password, secrets in configuration rather than in the database or the repository, and least-privilege access scoped to what each connection actually needs. Connections are documented: what talks to what, in which direction, how often, and with which credentials.
-
How do we know a sync is still running?
Scheduled work is logged with run history and alerting. The failure mode worth engineering against is not a sync that errors loudly, it is one that stopped three weeks ago and was noticed by a customer.