Building an integration that copes with failure
Agree the field map before any code
Most integration bugs are disagreements about data, not about HTTP. So the first deliverable is a table: each field, where it lives in WordPress (post meta, user meta, an order item, a form entry), where it goes in the other system, its format, and which side is the source of truth. We also decide what identifies a record on both sides. Matching on email alone creates duplicates the first time someone changes address, so we store the remote ID against the WordPress record after the first sync.
Take the call out of the page request
A visitor should never wait for someone else's API. When an order is paid or a form is submitted, we save a job and return the page. Action Scheduler picks the job up in the background, makes the call and records the result in its own tables. A timeout or a rate-limit response reschedules the job with a longer delay each time. After a set number of attempts it is marked failed and an administrator is notified. Nothing is dropped silently, and the queue screen shows what is still pending.
Webhooks need the same care as endpoints
An incoming webhook is a public URL that changes data, so we treat it as an attack surface. The signature is verified against the shared secret before the payload is trusted. The handler acknowledges quickly and queues the real work, because providers resend when a response is slow. Since the same event can arrive twice or out of order, we record event IDs and make every handler safe to run again. Stripe payment events are the classic case: process one twice and a customer gets two enrollments or two emails.
Pick authentication to match the client
Scripts in the browser of a logged-in user can rely on cookies and a REST nonce. A server or back-office tool calling WordPress is well served by application passwords, which are built into core and can be revoked per application. Many third-party platforms, Salesforce among them, use OAuth, with tokens that must be refreshed and stored carefully. A mobile app (see mobile app API integration) or a JavaScript front end usually gets short-lived tokens such as JWT. Whatever the method, every route has a permission callback that checks what this caller may do.
Logs you can read without a developer
Every outbound and inbound call is written to a log table with time, endpoint, status and a redacted payload. An admin screen filters by record, so when sales asks why a lead is missing, support can find the entry, read the error and press retry. Old rows are pruned on a schedule to keep the table small.