We've been building integrations since 2002 — starting with SOAP APIs when REST didn't exist yet, through the REST era, and now working with GraphQL, webhooks, FTP ingestion, and email parsing where the situation calls for it. Twenty-three years of connecting systems that need to share data.
The most common question in an integration project isn't "how do we build this?" It's "which method should we use?" The answer determines how real-time the data is, how robust the integration is under failure conditions, and how much it costs to maintain when the connected systems update.
Here's the plain guide to each method — what it is, when it's right, and when it isn't.
The six integration methods — what each actually does
REST API — Modern Standard
REST
Your system asks another system for data on demand. JSON over HTTPS. Most common approach today.
Best for
Fetching data on demand — "give me this customer's order history"
Creating or updating records in another system
Any integration where you control when data is retrieved
Most modern platforms — Zoho, Shopify, Salesforce, payment processors
Limitations
Polling for changes is inefficient — you're asking "anything new?" repeatedly
Not real-time if you're looking for event triggers
Rate limits mean you can't call as frequently as some use cases need
Webhooks — Real-Time Events
Webhooks
The other system calls your endpoint the moment something happens. Push, not pull. Instant notification.
Best for
Real-time event triggers — payment succeeds, order ships, status changes
Eliminating polling — instead of asking every 5 minutes, you're told instantly
Shopify order events, Stripe payment events, CRM stage changes
Any scenario where you need to react immediately when something happens
Limitations
Requires a publicly accessible endpoint to receive the webhook
Duplicate delivery possible — your endpoint must be idempotent
Need to handle failed deliveries and verify webhook signatures
GraphQL — Query Language
GraphQL
Ask for exactly the data you need — no more, no less. Shopify's Admin API uses this.
Best for
Platforms that expose GraphQL — Shopify Admin API, GitHub, others
Avoiding over-fetching — request exactly the fields you need
Complex data relationships where REST would require multiple calls
Limitations
Only available where the platform specifically exposes it
More complex to implement than REST for simple use cases
Caching is harder than with REST
SOAP — Legacy Protocol
SOAP / XML Web Services
The predecessor to REST. Still used in legacy ERPs, government platforms, financial services.
Best for
Legacy systems that only expose SOAP — no alternative exists
Government APIs and regulated financial platforms still running on SOAP
Enterprise ERPs from the 2000s that haven't migrated to REST
Limitations
Verbose XML format makes payloads large and hard to read
More complex to implement than REST
Increasingly rare — most platforms have migrated to REST
FTP / SFTP — File-Based Transfer
FTP / SFTP
Systems share data by dropping files. No API required. Monitored, validated, ingested automatically.
Best for
Suppliers who send order or inventory data as CSV exports
Legacy systems that can export files but have no API
Batch data transfers where real-time isn't required
Any system where "no API" is the constraint
Limitations
Not real-time — data is as current as the last file drop
File format changes break the pipeline — requires monitoring
Dependent on the sending party maintaining the export schedule
Email Parsing — No-API Ingestion
Email Parsing
Structured emails become the integration channel. When there's no API and no FTP — email is what's left.
Best for
Order confirmations, shipping notifications, invoice PDFs
Systems that generate consistent structured emails but have no API
Eliminating manual re-entry from email-based workflows
Limitations
Email format changes break the parser — requires monitoring
Dependent on consistent email structure from the sending system
Not suitable for large data volumes
Pull vs push — the most important distinction
Before choosing a method, understand whether you need pull (your system requests data when it wants it) or push (the other system notifies you when something happens). This distinction determines whether REST or webhooks is right — and it's where most integration architects get the decision wrong.
Pull — REST API polling
Your system asks "do you have any new orders?" every 5 minutes
The other system responds with whatever has changed
Your system processes the response
Repeat every 5 minutes, forever
Use when: You need data on demand. The other system doesn't support webhooks. Batch processing is acceptable. You need to retrieve historical data.
Push — Webhook
An order is placed in the other system
The other system immediately calls your endpoint
Your system processes the event in real time
Nothing happens until the next event
Use when: You need to react immediately when something happens. Polling latency is unacceptable. The other system supports webhooks (most modern platforms do).
"No API" is a constraint on the integration method — not a reason the integration can't be done. FTP and email parsing have connected systems that assumed they were unconnectable.
The decision table — situation to method
| If your situation is... | Use this method | Why |
|---|---|---|
| Modern SaaS platform (Zoho, Shopify, Salesforce) — fetching or updating data | REST API | All major SaaS platforms expose well-documented REST APIs. Standard, predictable, well-supported. |
| You need to react immediately when a payment, order, or status change happens | Webhook | Webhooks fire at the moment of the event. REST polling introduces latency that's often unacceptable for event-driven workflows. |
| Shopify Admin API integration | GraphQL | Shopify's Admin API uses GraphQL. Using it gives cleaner access to product and order data than working around it. |
| Legacy ERP or government platform — no REST API available | SOAP | If SOAP is what's exposed, SOAP is what you use. We've been building SOAP integrations since 2002. |
| Supplier sends CSV or Excel exports — no API exists | FTP / SFTP ingestion | Automated file ingestion pipeline — monitored, validated, imported. Same reliability as an API with proper error handling. |
| System sends structured confirmation emails — no API, no FTP | Email parsing | Structured emails become the integration channel. Parser extracts data, writes to system automatically. |
| High-volume data that needs precise field selection | GraphQL | GraphQL returns exactly the fields requested — no over-fetching. Efficient for high-volume integrations where bandwidth matters. |
| Multiple events that trigger different workflows (payment success vs payment failed) | Webhooks + REST | Webhooks for event triggers, REST for data retrieval on demand. Most complex integrations use both. |
What every integration needs — regardless of method
Retry logic with backoff
API calls fail — timeout, rate limit, temporary server error. Retry logic with exponential backoff means transient failures recover automatically. Without it, a 30-second API outage stalls your integration until someone notices.
Full audit logging
Every API call logged — request payload, response, timestamp, decision made. When a data discrepancy appears three weeks later, the audit log tells you exactly what happened. Essential for financial integrations.
Monitoring and alerting
Error rates, response times, queue depths tracked continuously. When something breaks, an alert fires immediately. You know about integration failures before your users do — not after they report missing data.
Idempotent processing
The same event can arrive more than once — webhook fires twice, file re-processed after a retry. Idempotent design means processing the same message multiple times produces the same result as once. No duplicate records, no double-charges.
Secure credential management
API keys and OAuth tokens stored securely — never in source code, never in plain text. Token refresh handled automatically. The KeyPay Marketplace extension we built is a published product handling payroll credentials — security is non-negotiable.
Documentation
Data flows mapped, credentials documented, error scenarios described with resolution steps. When the integration needs modification in two years, there's a clear record of how it was built. Without documentation, integrations become unmaintainable black boxes.
What to do when there's no API at all
✦ "No API" is a constraint — not a blocker
We've connected systems with no API, no FTP, and no obvious data exchange mechanism. The question we ask is: what data exchange mechanism does this system support?
Most systems support at least one of: structured file export (CSV, Excel) that can be automated, structured email notifications with consistent format, a report that can be scheduled, or a database that can be read directly with appropriate permissions.
The Atlantic LNG engagement is the clearest example: no direct database access permitted, no API, no FTP. We built a two-stream architecture using Excel staging exports and Microsoft PowerApps as a capture layer. Both fed into Power BI. The constraint shaped the approach — the outcome was a fully functional BI platform.
The rule: assess what the system can output, then build the ingestion mechanism around that output. No API doesn't mean no integration — it means a different integration method.
Most systems support at least one of: structured file export (CSV, Excel) that can be automated, structured email notifications with consistent format, a report that can be scheduled, or a database that can be read directly with appropriate permissions.
The Atlantic LNG engagement is the clearest example: no direct database access permitted, no API, no FTP. We built a two-stream architecture using Excel staging exports and Microsoft PowerApps as a capture layer. Both fed into Power BI. The constraint shaped the approach — the outcome was a fully functional BI platform.
The rule: assess what the system can output, then build the ingestion mechanism around that output. No API doesn't mean no integration — it means a different integration method.
Real integrations we've built — method and outcome
✦ From production integrations
Quickzy — bank verification + credit score (REST): Two REST API calls triggered automatically at defined pipeline stages in Zoho CRM. Bank verification fires on application receipt. Credit score fires if bank verification passes. Both with full retry logic, audit logging, and exception routing. Loan process automated from days to hours.
Shopify → Zoho Inventory (Webhooks + REST): Order placed in Shopify → webhook fires → stock committed in Zoho. Stock adjusted in Zoho → REST call updates Shopify quantity. Real-time bidirectional sync for Singapore wine manufacturer and Malaysia phone accessories manufacturer. Overselling eliminated.
Zoho ↔ KeyPay Marketplace extension (REST, published to Zoho Marketplace): Employee records, leave, and attendance sync from Zoho People to KeyPay via REST. 30+ AU/NZ businesses using it. Built to Zoho Marketplace security standards with OAuth credential management.
TSN — warehouse management integration (REST): Project created → REST queries to all warehouse APIs simultaneously → distance calculation → reserve and transfer or raise PO, decided automatically. The BOM reprioritization logic that uses these APIs was subsequently awarded US patents.
Atlantic LNG — Excel staging + PowerApps (no-API approach): No direct database access permitted. Excel exports deposited to SharePoint by system owners. PowerApps forms for data with no digital source. Both ingested by Power BI. Full executive and departmental dashboards delivered without touching a production system.
Shopify → Zoho Inventory (Webhooks + REST): Order placed in Shopify → webhook fires → stock committed in Zoho. Stock adjusted in Zoho → REST call updates Shopify quantity. Real-time bidirectional sync for Singapore wine manufacturer and Malaysia phone accessories manufacturer. Overselling eliminated.
Zoho ↔ KeyPay Marketplace extension (REST, published to Zoho Marketplace): Employee records, leave, and attendance sync from Zoho People to KeyPay via REST. 30+ AU/NZ businesses using it. Built to Zoho Marketplace security standards with OAuth credential management.
TSN — warehouse management integration (REST): Project created → REST queries to all warehouse APIs simultaneously → distance calculation → reserve and transfer or raise PO, decided automatically. The BOM reprioritization logic that uses these APIs was subsequently awarded US patents.
Atlantic LNG — Excel staging + PowerApps (no-API approach): No direct database access permitted. Excel exports deposited to SharePoint by system owners. PowerApps forms for data with no digital source. Both ingested by Power BI. Full executive and departmental dashboards delivered without touching a production system.
The honest summary
The right integration method is determined by what the connected systems support, how real-time the data needs to be, and what happens when things fail. Not by preference or convention.
REST is the modern standard and covers most use cases well. Webhooks handle real-time event triggers better than polling ever will. GraphQL wins when precision data fetching matters. SOAP is legacy but still necessary for legacy systems. FTP and email parsing solve the "no API" problem that appears more often than people expect.
What every integration needs — regardless of method — is error handling, retry logic, audit logging, monitoring, and documentation. These aren't extras. They're what separates integrations that run reliably for five years from integrations that fail silently for three days before anyone notices.
If you're unsure which method fits your situation — or if you have systems that seem impossible to connect — that's the conversation we start every integration engagement with. The answer almost always exists.
Systems that need to share data automatically?
Free integration consultation — we map your systems, assess what's available, and recommend the right method. 23 years from SOAP to webhooks. ISO 27001.