Service · APIs & Integrations
When your systems need to share data, the integration should be built to last, not held together with no-code duct tape.
Third-party connectors handle simple, linear workflows. When your use case involves conditional logic, OAuth token management, webhook processing, bidirectional data sync, or a platform whose Zapier connector doesn't expose the fields you need, you need code. ArdinGate builds custom REST APIs and third-party integrations in PHP: scoped from a documented spec, built with a service layer that survives upstream API changes, and delivered with documentation that makes the handoff straightforward whether the next developer is in-house or another contractor.
What a well-built API integration requires
API work looks simple from the outside: connect system A to system B, data moves, done. In practice, every integration involves a set of architectural decisions that determine whether the connection holds up under production conditions or breaks the first time an edge case, an upstream change, or a rate limit appears. Here are the key components that ensure each of those decisions holds up.
A data flow spec before any code is written
The most expensive integrations are ones where the developer starts connecting things before mapping what data needs to move, in which direction, under what conditions, and what happens when the external service returns an error rather than a success. Every project starts with a spec: which endpoints are called, what triggers each call, what data gets sent, what the expected response schema looks like, what events trigger webhook delivery, and what the consuming application does when the response is a 4xx or 5xx instead of a 200. This upfront work takes a few hours and prevents the most common failure mode: discovering mid-build that the platform doesn't expose the endpoint you needed, the OAuth flow requires a browser redirect that doesn't fit a server-side architecture, or the data field you needed is behind a paid tier that wasn't budgeted. The spec is a shared document reviewed and approved before build begins, not an assumption in the developer's head that surfaces as a change order three weeks later.
A service layer that isolates external dependencies
Integrations built by scattering API calls through application code (a Stripe charge in a checkout controller, a Mailchimp subscribe call in a form handler, a QuickBooks sync buried in an order processor) become a maintenance problem the first time any of those external services updates its interface, deprecates a parameter, or changes a response schema. The correct architecture isolates all external API communication behind a dedicated service class or file per integration. One file owns every call to Stripe. One file owns every call to QuickBooks. When Stripe releases a breaking change, the fix is localized to one file. The consuming code (checkout controllers, admin panels, background jobs) calls the service layer function and gets back a result, without knowing or caring which HTTP endpoint was called, what parameters were sent, or what the response body looked like. This design makes integrations testable in isolation, replaceable without touching business logic, and comprehensible to any developer who inherits the codebase later.
Authentication that does not break when credentials rotate
API authentication fails in predictable, avoidable ways. Credentials stored in source code get committed to version control. OAuth access tokens expire and the application has no refresh logic, so the integration silently stops working until someone notices. API keys are hardcoded to one environment and the staging instance uses production credentials. Every integration is built with credentials in environment variables, never in code. OAuth implementations include token storage, expiry detection, and automatic refresh flows so the integration doesn't fail silently when an access token expires. API key integrations come with documented rotation procedures (what to update, where, and in what order) so your team can rotate compromised or expiring credentials without scheduling a developer engagement. For custom APIs built for external consumers, API key issuance, revocation, and scope management are first-class admin functions built into the system, not manual database operations.
Webhook receivers that verify, queue, and respond correctly
A webhook receiver that works correctly in a test environment can still fail in production for three reasons that most quickly-built receivers don't address. First, signature verification: every major platform signs its webhook payloads with HMAC, and verifying that signature is the only thing that prevents any actor on the internet from sending fabricated events to your receiver endpoint. Stripe uses HMAC-SHA256; GitHub, Twilio, Mailchimp, and most others use equivalent mechanisms. Signature verification runs before any payload is processed, not as an afterthought. Second, idempotency: webhooks are delivered at-least-once, not exactly-once. A receiver that processes a payment.succeeded event twice must not double-fulfill the order. Idempotency keys or event ID tracking prevent duplicate side effects without rejecting the second delivery. Third, response timing: a receiver that runs complex synchronous processing against a 30-second timeout will fail for high-latency operations. The correct pattern acknowledges the event immediately with a 200 and queues the processing work asynchronously, keeping the delivery channel clear while the actual work happens on your schedule.
Rate limiting and graceful degradation for upstream failures
Third-party APIs impose rate limits. They also go down. An integration that accounts for neither will surface as mysterious application errors that appear to be your application's fault but are actually the upstream service returning 429 Too Many Requests or 503 Service Unavailable. Rate limit responses are handled with exponential backoff for idempotent operations (retrying with increasing delays rather than hammering the endpoint) and a queuing approach for high-volume batch jobs that would exceed per-minute limits if processed synchronously. API outages trigger graceful degradation: a Mailchimp outage doesn't crash a checkout flow; a Twilio unavailability doesn't block a contact form from submitting. Every error is logged with the full request context (endpoint called, parameters sent, response code and body received, timestamp, caller identity) so failures are diagnosable from logs without reproducing the exact conditions that caused them. Your on-call developer should never need to guess at what an error means.
Documentation and a Postman collection that make the handoff real
Every custom REST API is delivered with documentation covering every endpoint: HTTP method, full URL path, required and optional parameters with types and constraints, example request bodies, example success and error response bodies, authentication header format, rate limit behavior, and the meaning of every non-200 status code the API returns. This is delivered as a Postman collection importable and runnable against your environment immediately—not a PDF that describes what requests look like but doesn't let you run them. Third-party integration projects are delivered with implementation notes covering the architecture decisions, the webhook event types handled, the failure and retry behavior, credential storage locations, and rotation procedures. The documentation standard is: a developer who was not involved in the build should be able to read the documentation, run the Postman collection against the staging environment, and understand the integration well enough to extend it without scheduling a call with the original developer.
What a technical buyer evaluates before commissioning API work
API development buyers are usually technical themselves, or they have a technical stakeholder whose job is to vet the developer before a contract is signed. The evaluation is specific and hard to fake your way through: vague answers to concrete technical questions are immediately disqualifying. Here's what a careful buyer evaluates at each stage and why it matters.
Auth model: does the developer default to the right mechanism for the use case?
A developer who recommends OAuth 2.0 client credentials for an internal server-to-server integration where both systems are under your control isn't necessarily wrong, but they're overcomplicating a situation where a rotatable API key solves the same problem in a fraction of the code and operational overhead. Conversely, one who recommends API keys for an integration where a third-party developer ecosystem needs scoped, revocable, per-client access is under-designing for the security requirement. Technical buyers probe auth recommendations specifically: not "how do you handle auth" in the abstract, but "for our specific scenario with X type of consumer and Y data sensitivity, what would you use and why?" A developer with a specific, tradeoff-aware answer has designed auth for production scenarios before. One who gives a generic answer has not.
Error handling: what happens at failure, not just at success?
Buyers who have been burned by a previous API integration know the happy path always works in demo. What they are evaluating is what happens when the external service returns a 429, when a webhook payload arrives with an unexpected field that did not exist in the documentation, when an OAuth token expires between the refresh check and the API call, when a Stripe payment is declined with a specific decline code that requires different application behavior than a generic payment failure. The diagnostic question is: "walk me through what your webhook receiver does when it gets the same event twice." A receiver that was designed for this case has a specific, immediate answer involving idempotency keys or event ID deduplication. One that wasn't has a lot of "it depends" and "we'd handle that in a follow-up," which is exactly what you will hear after the project is delivered, too.
Codebase portability: can another developer pick this up without you?
Technical decision-makers commissioning API work are often specifically trying to avoid creating a vendor dependency. The question behind "what does the handoff look like?" is: "if we need to hand this to our in-house developer or a different contractor in 18 months, can they work with it without you being involved?" Buyers evaluate this by asking for example documentation, a code sample from a previous project, or a walkthrough of how the service layer is structured. They seek evidence that delivered code is organized around clear responsibilities, named consistently, free of magic constants and unexplained side effects, and accompanied by documentation that explains decisions, not just mechanics. Integration code that requires the original developer to explain it verbally before anyone else can modify it is not a deliverable; it's a dependency. That distinction separates a developer who builds things you own from one you will need to keep on retainer indefinitely.
Spec process: does the developer scope from documentation or from description?
API projects have a failure mode specific to them: the developer scopes the project from a description of what you want without reading the third-party platform's actual documentation first. Build starts. They discover mid-project that the platform does not expose the endpoint you needed, the OAuth flow requires a browser redirect that doesn't fit the server-side architecture you described, or the data you needed is behind a paid tier that wasn't in the budget. At that point the scope expands, the price revises upward, and you're three weeks in with something half-built. Buyers who have been through this ask specifically: do you read the full API documentation before scoping? Do you build a proof-of-concept for the auth flow before quoting the full integration? Do you identify platform limitations upfront? The answer should be yes to all three, with specifics.
Data ownership: where does your data go and who can see it?
For integrations handling sensitive data (customer PII, payment information, health records, financial data), technical buyers ask a question that generic API providers rarely think about: where does the data transit, and who has access to it in flight? When an integration is built using a third-party automation platform like Zapier or Make, your customer data moves through that platform's servers on every execution. You have agreed to their data processing terms; your customers have not necessarily been informed. Custom code running on your own server processes the data on your infrastructure, in your environment, with no third-party transit unless you explicitly call an external endpoint. For any use case that involves personal data subject to GDPR, HIPAA, CCPA, or PCI DSS obligations, where data transits and who can access it in transit is a compliance question, not a preference question.
How the API development inquiry funnel actually works
API and integration buyers arrive differently than businesses shopping for a new website. They're not browsing a service category; they have a specific, concrete problem that has reached the point where manual workarounds are no longer acceptable. The evaluation happens faster, the buyer is more informed, and the conversion depends almost entirely on whether the developer demonstrates technical judgment during the pre-contract phase.
Stage 1: The trigger. Integration projects are driven by a specific event. The team has been copying data between two systems by hand for long enough that the error rate or the person-hours required are no longer acceptable. A new tool has been adopted and needs to stay in sync with existing systems. A business partnership requires a data feed that doesn't exist. A mobile app needs a backend API to call. A Zapier workflow hit the 15-step limit and needs to be rebuilt in code. The buyer arrives with a defined problem, not a vague sense that their tech stack could improve, and they want a developer who understands the problem specifically, not one who offers generic reassurances about "seamless integration."
Stage 2: The technical evaluation. From the service page, buyers work through a fast credibility check. Which platforms have you integrated with? How do you handle rate limits? What does your service layer architecture look like? Do you require the client to own the third-party API account and credentials, or do you hold them? Copy that resonates with this buyer is specific and technical. Vague claims about "connecting any system" without specifics about how (particularly without mentioning the constraints that make API integration complex) read as marketing to someone who knows enough to ask detailed questions. The content on this page is written to answer those questions before the buyer has to ask them, which moves the conversation to the quote stage faster.
Stage 3: The quote breakdown point. The funnel most often breaks at scoping. API buyers have frequently been burned by a previous developer who quoted a fixed price without reading the platform's documentation, started building, discovered a constraint that made the project significantly more complex, then revised the price or delivered something incomplete. The buyer is evaluating whether this developer's scoping process is rigorous enough to prevent that from happening again. The discovery call is where rigor shows: asking the right questions about data direction, auth requirements, event handling, error scenarios, and volume expectations (before any code is discussed) signals a process that produces reliable estimates.
Stage 4: Post-delivery confidence. Because API work is infrastructure (it runs continuously in the background without a human reviewing it), buyers care about what happens after delivery. Who maintains it when the upstream API changes? What is the process for rotating credentials? How are errors surfaced? A developer who answers those questions during the sales conversation, rather than after the project is delivered, is the one who earns the contract from a buyer who has been through a difficult API project before.
Custom code vs. no-code connectors vs. building it yourself
The answer to "should I use Zapier, Make, or custom code?" depends on the workflow. Here is a straight comparison across the factors that matter.
| Factor | Zapier / Make | Custom code (ArdinGate) |
|---|---|---|
| Setup time | Hours for simple flows | Days to weeks, depending on scope |
| Conditional logic | Limited to filter steps and basic path routing | Arbitrary logic (any condition, any branching) |
| Data volume cost | Per-task billing compounds at scale | Zero marginal cost per execution on your server |
| Error visibility | Generic failure email with abstracted details | Structured logs with full request/response context |
| Data transit | Through the connector platform's servers | Your server only, unless you call an external endpoint |
| API coverage | Limited to what the connector exposes | Full API surface (any endpoint, any parameter) |
| Dependency risk | Platform must stay in business and maintain your connector | Runs on your infrastructure, owned code, no platform dependency |
| Maintenance on upstream change | Fix in the GUI when the connector breaks | Fix in one service file, covered by documented architecture |
| Compliance suitability | Depends on platform's DPA terms | Data stays in your environment; you control the compliance posture |
Pricing
API work is priced by complexity and scope, not by hours. Every project is quoted fixed-price after a discovery call that maps the data flow, confirms the platform documentation supports the integration as described, and defines exactly what gets built. Scope ambiguity is the primary cause of cost overruns on API projects, so no work begins until the spec is signed.
Single third-party integration — straightforward ($400–$700): Integrations with well-documented platforms, one directional data flow, API key auth, no OAuth, no webhooks, and no conditional logic. Examples: adding a Mailchimp list subscription to a contact form, triggering a Twilio SMS from a form submission, sending a Stripe payment intent and handling the success response.
Single third-party integration — complex ($800–$1,500): Integrations requiring OAuth 2.0 token management and refresh flows, webhook receivers with HMAC signature verification and idempotency handling, bidirectional data sync between two systems, conditional routing logic based on response data, or platforms with less developer-friendly documentation requiring more discovery time. Examples: QuickBooks OAuth sync, a full Stripe integration handling multiple payment types and event-driven webhooks, a scheduling platform integration with availability checks and cancellation logic, HubSpot CRM sync with deal stage routing.
Custom REST API development (from $2,000): Building an API your application, partner systems, or internal tools will call. Starts around $2,000 for a small API with three to five endpoints, API key authentication, rate limiting, a documented data model, and a Postman collection. APIs with OAuth 2.0, multiple consumer types, versioning, complex data models, and full developer documentation are scoped individually after a discovery call. All custom API builds include endpoint documentation, a Postman collection, and implementation notes.
API work can be scoped alongside a new website build or as a standalone project for an existing site or application. Website builds start at $1,200 for a single-page site and $2,800–$5,000 for a multi-page build — API integrations on top of a website are quoted as a line item added to the website scope. See full website pricing →
API development questions
What is the difference between an API and a webhook?
An API is a request-response mechanism your code initiates: you call an endpoint and receive data or a confirmation in return. A webhook reverses that direction: an external service sends an HTTP POST to your server when an event occurs, without you asking for it. A payment succeeds, a booking is confirmed, an inventory level drops—the external platform fires the webhook and your receiver acts on it. Most integration projects involve both patterns working together. Your site calls the Stripe API to create a charge, then a Stripe webhook confirms the charge succeeded so your database can mark the order as paid. Understanding which direction data flows at each step determines whether you build an outbound API call, a polling loop, or an inbound webhook receiver. Choosing the wrong pattern produces integrations that are fragile, slow, and unnecessarily complex: polling for events a webhook would deliver instantly, or building elaborate retry loops for things that only need a one-time request.
Which third-party services can you integrate with?
Any platform with a documented REST API or webhook system is in scope. Common integrations: Stripe and Square for payment processing; Twilio for SMS, voice, and WhatsApp; Mailchimp, Klaviyo, and Resend for email marketing and transactional email; QuickBooks and Xero for accounting sync; Google Workspace APIs for Calendar, Sheets, and Drive; HubSpot and Pipedrive for CRM; Calendly and Acuity for scheduling; DocuSign for e-signature; EasyPost and ShipStation for shipping; and Zapier or Make as intermediate connector bridges when the architecture calls for it. If the platform has an authentication mechanism (API key, OAuth 2.0, JWT, HMAC-signed webhooks), it can be integrated. Platforms without a public API sometimes have workarounds via IMAP or webhook emulation, but those are flagged during scoping as higher-maintenance options with known tradeoffs rather than treated as equivalent to a documented API.
How much does API development or integration cost?
Third-party API integrations with well-documented platforms are quoted fixed-price after a scoping call. Straightforward integrations with one directional data flow, API key auth, and no webhooks run $400–$700. Complex integrations with OAuth token management, webhook receivers, bidirectional sync, or conditional routing logic run $800–$1,500. Custom REST API development—building endpoints your own app, partners, or internal tools will call—starts around $2,000 for a small authenticated API with three to five endpoints, rate limiting, a documented data model, and a Postman collection. Larger APIs with OAuth, multiple consumer types, versioning, and full developer documentation are scoped after a discovery call. All pricing is fixed after the spec is written, with no hourly estimates that expand mid-project when a platform constraint appears the developer didn't anticipate during scoping. See full pricing →
Do you build the front-end as well, or just the API layer?
Either approach works. Some projects need the back-end API only—the consuming application exists, or another developer is building the front-end and needs the API delivered to a spec they can connect to cleanly. Others need the full stack: the PHP API layer, the website or admin interface that calls it, and the third-party integrations wired together. API work is scoped and priced independently of website work, so it can be added to a new website build, bolted onto an existing site, or delivered as a standalone project for a mobile app, partner system, or internal tool to consume. When ArdinGate is not building the front-end, the API delivery includes a Postman collection, endpoint documentation covering every route and response schema, and example requests and responses for every success and error case—everything the consuming developer needs to connect without scheduling a handoff call.
How is authentication handled on a custom API?
The right authentication mechanism depends on who is consuming the API and what the security and operational requirements are. For server-to-server integrations where both ends are under your control, rotatable API keys with IP allowlisting are ideal: low overhead, easy to rotate, no user interaction required. For APIs consumed by third-party developers or partner systems with multiple callers, OAuth 2.0 client credentials flow provides token-based auth with expiry, scope control, and per-client revocation. For APIs consumed by a browser front-end on behalf of a logged-in user, JWT or session-based authentication tied to the existing user system is appropriate. Every implementation includes rate limiting on the authentication endpoint, structured request logging for audit purposes, and documented credential rotation procedures. Credentials are stored in environment variables: never in source code, never committed to version control, never hardcoded to a specific environment.
What rate limiting and error handling is included?
Rate limiting runs server-side using file-based or Redis-backed counters, applied per API key or per IP depending on the auth model. Limits are configurable per endpoint and per consumer tier, with separate thresholds for internal and external callers when the API serves both. A rate-limited request returns 429 Too Many Requests with a Retry-After header, not a generic 500 error that makes the caller retry immediately and compound the issue. On the error handling side, every integration with a third-party service uses structured exception handling covering network timeouts, authentication failures, upstream rate limit responses, malformed response bodies, and partial failures in multi-step workflows. Errors are logged with full request context: endpoint, parameters, response code and body, timestamp, caller identity, so any failure is diagnosable from logs without reproducing the exact conditions that caused it. Website security basics →
What happens when a third-party API changes or goes down?
Third-party API changes are one of the primary design concerns in integration architecture, and the service layer pattern exists specifically to contain the blast radius when they occur. All external API communication is isolated in a dedicated service class or file per integration: one file owns every call to Stripe, one file owns every call to QuickBooks. When Stripe deprecates a parameter or changes a webhook payload schema, the fix is localized to one file rather than requiring a codebase-wide search-and-replace. API versioning is pinned where the provider supports it, so upstream changes to the default API version do not silently break existing integrations. For outages, the integration layer includes retry logic with exponential backoff for idempotent operations and graceful degradation for non-critical calls: a Mailchimp outage doesn't crash your checkout flow, and Twilio unavailability doesn't block a contact form submission.
What documentation is delivered with the API?
Custom REST APIs are delivered with endpoint documentation covering every route: HTTP method, full path, required and optional parameters with data types and constraints, example request bodies, example success and error response bodies, authentication header format, rate limit behavior, and the meaning of every non-200 status code the API returns. Documentation arrives as a Postman collection—importable and runnable against your environment immediately—and as a Markdown document suitable for a developer README or internal wiki. Third-party integration projects are delivered with implementation notes covering architectural decisions, webhook event types handled, retry and failure behavior, credential storage locations, and rotation procedures. The documentation standard: a developer who was not involved in the build should be able to read the docs, run the Postman collection, and understand the integration well enough to extend or modify it without scheduling a call with the original developer.
Can you add an API to an existing website that was not built with one?
Yes, and this is a common project type. An existing PHP site that processes contact forms, bookings, or orders can have an API layer added on top of the same database and business logic without disrupting the existing site. The standard approach adds a dedicated API router under a path prefix like /api/v1/ that coexists with the existing page routing: no routing conflicts, no downtime on the live site. The existing database schema may need additions to expose data the API needs, and existing business logic is extracted into shared functions the API controllers call rather than duplicated. For sites built on WordPress or another platform, feasibility depends on what the platform exposes and whether a standalone PHP API can run alongside it. Platform constraints affecting the architecture get surfaced during the discovery call, not after build starts.
Who owns the source code and API credentials after delivery?
You own all of it outright. Full source code ownership transfers at project completion with no licensing fees, no ongoing technical dependency, and no lock-in to ArdinGate for future changes or maintenance. The codebase is documented well enough that any competent PHP developer can pick it up and work with it without the original developer's involvement. API keys, OAuth credentials, and webhook secrets are yours: generated in your accounts, stored in your environment, rotated by your team using the rotation procedures delivered with the project. If the project later needs additional endpoints, a different auth model, or an expanded data model, that work can be scoped as a follow-on with ArdinGate or handed to any other developer. The delivered Postman collection and documentation travel with the codebase and are yours to share with whoever maintains the system going forward.
How long does an integration or API build take?
A single third-party API integration with a well-documented platform (Stripe basic checkout, Mailchimp list subscription, Twilio SMS send) takes one to two weeks from a signed scope to delivery and testing. Complex integrations with OAuth flows, webhook receivers with conditional processing, or bidirectional sync run two to four weeks. Custom REST API builds are scoped per project during discovery. A small API with three to five endpoints, API key auth, and a documented data model runs two to three weeks. An API with OAuth, multiple consumer types, versioning, and a full Postman test suite runs four to six weeks. These estimates assume a signed spec with no open scope questions. Scope ambiguity (particularly undiscovered platform constraints) is the primary driver of timeline slips on API projects. The pre-build discovery process exists specifically to surface those constraints before work starts, not after.
Why not just use Zapier or Make instead of custom code?
Zapier and Make are correct for linear trigger-to-action workflows with low data volume, no conditional branching beyond basic filters, and connectors that expose exactly the fields your use case requires. If that describes your situation, use them—faster to set up, lower upfront cost, no code maintenance. The case for custom code is when any of those conditions stop being true: your workflow requires conditional logic the visual flow builder can't express cleanly; your per-task volume makes subscription billing expensive compared to running code on your own server at zero marginal cost; you need structured error logs with request context when something fails rather than a generic notification; the platform's connector doesn't expose the endpoint or field you need; or you have data privacy requirements that make routing sensitive data through a third-party automation platform's infrastructure a compliance issue. Custom code offers no per-task billing, runs on your infrastructure, and gives you complete visibility into what it's doing and why.
Related services and guides: web application development · client portal development · payment integration · online booking integration · website security basics · custom PHP development · web app cost guide
Have two systems that need to share data?
Tell me what you're connecting, which direction the data flows, and what needs to happen when it gets there. I'll read the API documentation, identify the constraints, and give you a fixed scope and price before any code is written.
Get a quote