Service · APIs & Integrations
API development and integrations built to last
Simple connectors handle linear workflows; conditional logic, OAuth, webhooks, bidirectional sync, or missing Zapier fields need code. You get PHP REST APIs and integrations built from documented specs, with upstream changes isolated in a service layer and documentation your own team or a contractor can pick up.
What a well-built API integration requires
Connecting systems requires architecture that survives production edge cases, upstream changes, and rate limits. The components below determine whether integrations keep working when those conditions arise.
A data flow spec before any code is written
Starting connections before mapping data, direction, conditions, and external errors creates expensive integrations. Every project starts with a spec covering:
- Which endpoints are called and what triggers each call
- What data gets sent and what the expected response schema looks like
- What events trigger webhook delivery
- What the consuming application does when the response is a 4xx or 5xx instead of a 200
A few hours of upfront scoping expose missing endpoints, browser-redirect OAuth incompatible with server-side architecture, or unbudgeted paid-tier fields. You review and approve a shared spec before development, avoiding surprise change orders three weeks later.
A service layer that isolates external dependencies
Scattered Stripe checkout charges, Mailchimp form subscriptions, and QuickBooks order syncs complicate updates, parameter deprecations, and schema changes. Each integration instead owns a dedicated service class/file: all Stripe calls together, all QuickBooks calls together. Breaking changes stay local. Checkout controllers, admin panels, and background jobs receive results without handling endpoints, parameters, or response bodies. Integrations become independently testable, replaceable without business-logic changes, and understandable to future developers.
Authentication that does not break when credentials rotate
Code-stored credentials leak into version control; missing OAuth refresh silently stops integrations; hardcoded keys put production credentials in staging. I use environment variables, stored OAuth tokens with expiry detection and automatic refresh, and documented key rotation steps specifying what, where, and order. Your team can replace compromised/expiring keys without hiring a developer. Custom APIs provide admin functions for key issuance, revocation, and scope management, avoiding manual database edits.
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:
- Signature verification. Major platforms sign webhooks with HMAC to prevent fabricated events: Stripe uses HMAC-SHA256; GitHub, Twilio, Mailchimp, and others use equivalents. Verify before processing any payload.
- 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.
- Response timing. Complex synchronous work can exceed a 30-second timeout. Acknowledge immediately with 200, then queue asynchronous processing to keep delivery clear.
Rate limiting and graceful degradation for upstream failures
Upstream 429 Too Many Requests or 503 Service Unavailable can masquerade as application errors. Idempotent operations retry with exponential backoff; queues keep batch jobs within per-minute limits. Graceful degradation keeps Mailchimp outages from crashing checkout and Twilio outages from blocking contact forms. Logs capture endpoint, parameters, response code/body, timestamp, and caller, enabling diagnosis without reproduction or on-call guesswork.
Documentation and a Postman collection that make the handoff real
Every REST endpoint is documented: HTTP method, full URL path, required/optional parameters with types/constraints, request/success/error examples, auth headers, rate limits, and non-200 meanings. A Postman collection runs immediately in your environment, unlike a descriptive PDF. Integration notes cover architecture, webhook events, retries/failures, credential locations, and rotation. New developers can read the docs, run staging requests, and extend integrations without calling the original developer.
What to check before you commission API work
Before you sign with an API developer, ask concrete questions. A vague answer is a red flag. Here's what to check and why.
Auth model: does the developer default to the right mechanism for the use case?
OAuth 2.0 client credentials can overcomplicate internally controlled server-to-server links; rotatable keys need less code and overhead. Conversely, third-party ecosystems need scoped, revocable per-client access beyond simple keys. Ask which mechanism fits your consumers and how sensitive your data is, and why. Specific tradeoffs demonstrate production auth experience; generic answers don't.
Error handling: what happens when a request fails as well as when it succeeds?
Demos prove the happy path. Ask about 429 responses, undocumented webhook fields, OAuth expiry between refresh checks and calls, and Stripe decline codes needing distinct behavior. Ask what happens when a webhook event arrives twice. Prepared receivers use idempotency keys or event-ID deduplication; vague promises of later handling predict the same response after delivery.
Codebase portability: can another developer pick this up without you?
Ask whether another developer could maintain the system in 18 months. Example docs, prior code samples, and service-layer walkthroughs should demonstrate clear responsibilities, consistent names, no magic constants/unexplained side effects, and documented decisions/mechanics. Code requiring the original developer's verbal explanation creates an indefinite retainer dependency, not independent ownership.
Spec process: does the developer scope from documentation or from description?
Quoting before reading API docs risks discovering missing endpoints, incompatible browser-redirect OAuth, or unbudgeted paid-tier data mid-build. Three weeks later, scope/pricing expand around unfinished work. Before you accept a quote, ask for three specific commitments: read full documentation, prove the auth flow, and identify platform limits. Each answer should be yes, with details.
Data ownership: where does your data go and who can see it?
For personal, payment, health, or financial data, you need to know where it travels and who can access it. Zapier or Make routes each execution through third-party servers under terms you've accepted, potentially without informing customers. Custom server code stays on your infrastructure unless explicitly calling external endpoints. For GDPR, HIPAA, CCPA, or PCI DSS obligations, transit and access are compliance questions.
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 |
|---|---|---|
| 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
Full breakdown, including what moves the price and how it compares with subscriptions: How much does an API integration cost?
Fixed pricing reflects scope/complexity. Discovery maps data flow, verifies platform documentation, and defines deliverables. Scope ambiguity drives overruns; development begins only after the spec is signed.
- Straightforward integration ($750–$1,500): Documented platforms, one-way flow, key auth; no OAuth, webhooks, or conditional logic. Examples: Mailchimp contact-form subscription, Twilio submission-triggered SMS, Stripe payment intent/success handling.
- Complex integration ($2,500–$5,500): OAuth 2.0 refresh/management, HMAC-verified idempotent webhooks, two-system bidirectional sync, response-based routing, or extra discovery for weak docs. Examples: QuickBooks OAuth sync; Stripe payment types/event webhooks; scheduling availability/cancellations; HubSpot deal-stage routing.
- Custom REST API (from $2,000): For apps, partners, or internal tools. $2,000–$4,000 covers three to five endpoints, key auth, rate limits, documented model, and Postman collection. OAuth 2.0, multiple consumers, versioning, complex models, or full developer docs run $10,000–$20,000 after discovery. Every build includes endpoint docs, Postman collection, and implementation notes.
API work can accompany new builds or stand alone for existing sites/apps. Website prices start at $1,200 single-page or $2,800–$5,000 multi-page; integrations are separate scope line items. Managed hosting is billed monthly: Core $60/mo, Care $100/mo, or Priority $180/mo. Full website pricing →
Get a number for your integration now: Cost estimator →
API development questions
What is the difference between an API and a webhook?
Your code initiates API requests and receives data/confirmation. Webhooks reverse direction: external services POST events such as payments, bookings, or inventory drops to your receiver. Most projects combine both: call Stripe to charge, then its webhook marks the database order paid. Flow direction determines outbound calls, polling, or inbound receivers. Wrong choices add fragility, delay, and complexity, such as polling instead of instant webhooks or elaborate retries for one-time requests.
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
- Zapier or Make as intermediate connector bridges when the architecture calls for it
Platforms supporting API keys, OAuth 2.0, JWT, or HMAC-signed webhooks are integrable. Without public APIs, IMAP/webhook-emulation workarounds may exist; scoping flags their higher maintenance and tradeoffs.
How much does API development or integration cost?
Fixed quotes follow scoping/specification: $750–$1,500 for a documented, one-way, key-auth integration without webhooks; $2,500–$5,500 for OAuth management, webhooks, bidirectional sync, or conditional routing; $7,000–$13,000 when several systems are wired together. Custom REST endpoints for apps/partners/internal tools start around $2,000: three to five endpoints, auth, rate limits, documented model, Postman collection. Larger OAuth APIs with multiple consumers, versioning, and full docs run $10,000–$20,000 after discovery. No expanding hourly estimates for unanticipated platform constraints. Full pricing →
Do you build the front-end as well, or just the API layer?
Either: API-only to a spec for existing apps/another developer's front-end, or full-stack PHP API, website/admin interface, and integrations. Independently scoped/priced API work fits new or existing sites, standalone mobile apps, partners, or internal tools. If I'm not building the front-end, delivery includes a Postman collection, every route/response schema, and requests/responses for all success/error cases, enabling connection without a handoff call.
How is authentication handled on a custom API?
Consumer/security/operational needs determine auth: controlled server-to-server links use easily rotated, low-overhead API keys with IP allowlisting, no user interaction; multiple partner/developer callers use OAuth 2.0 client credentials with expiry, scopes, per-client revocation; logged-in browser users use JWT/sessions tied to existing accounts. All include auth-endpoint rate limits, structured audit logs, and rotation documentation. Environment variables keep credentials outside source/version control and avoid environment-hardcoding.
What rate limiting and error handling is included?
Server-side file/Redis counters limit keys/IPs by endpoint and consumer tier, with separate internal/external thresholds. Return 429 Too Many Requests and Retry-After, avoiding 500-driven immediate retries. Structured exceptions cover timeouts, auth failures, upstream limits, malformed responses, and partial multi-step failures. Logs record endpoint, parameters, response code/body, timestamp, and caller for diagnosis without reproduction. Website security basics →
What happens when a third-party API changes or goes down?
Dedicated service files isolate external calls: one for Stripe, another for QuickBooks. Stripe parameter deprecations/webhook schema changes require local fixes, not codebase-wide replacement. Pin supported API versions to prevent silent breakage from default changes. Idempotent calls retry with exponential backoff; noncritical calls degrade gracefully: Mailchimp outages won't crash checkout, and Twilio outages won't block contact submissions.
What documentation is delivered with the API?
REST docs cover every route's method/path, required/optional parameter types/constraints, request/success/error examples, auth headers, rate limits, and non-200 meanings. Delivery includes an immediately runnable Postman collection and Markdown for README/wiki use. Integration notes explain architecture, webhook events, retries/failures, credential locations, and rotation. Uninvolved developers can read, run, modify, and extend without an original-developer call.
Can you add an API to an existing website that was not built with one?
Yes, commonly. Existing PHP forms/bookings/orders gain APIs sharing their database and logic. A dedicated /api/v1/ router coexists without routing conflicts or downtime. Schema additions may expose needed data; shared functions extract business logic instead of duplicating it. WordPress/other platforms depend on exposed capabilities and whether standalone PHP can run alongside them. Discovery identifies architectural constraints before development.
Who owns the source code and API credentials after delivery?
You own all source at completion, with no licensing fees and no lock-in. Documentation enables any competent PHP developer to maintain it independently. API keys, OAuth credentials, and webhook secrets originate in your accounts, reside in your environment, and rotate through your team using supplied procedures. I or another developer can add endpoints, change auth, or expand data models. The Postman collection/docs remain yours to share with maintainers.
How long does an integration or API build take?
Signed scope to tested delivery: documented Stripe checkout, Mailchimp subscriptions, or Twilio SMS integrations take one to two weeks; OAuth, conditional webhooks, or bidirectional sync, two to four. Discovery-scoped REST APIs: three to five endpoints with key auth/documented model, two to three weeks; OAuth, multiple consumers, versioning, and full Postman tests, four to six. These assume resolved scope; discovery exposes platform constraints, the main source of ambiguity and delays.
Why not just use Zapier or Make instead of custom code?
Use Zapier or Make for low-volume linear workflows, basic filters, and connectors exposing every required field: faster setup, lower upfront cost, no code maintenance. Custom code suits complex branching, expensive per-task subscriptions, missing endpoints/fields, detailed contextual error logs, or privacy constraints against third-party transit. It runs on your infrastructure at zero marginal task cost, with complete visibility into behavior and reasons. Run the numbers for your workflows: Zapier vs. custom integrations.
Can you add AI to my CRM or custom software?
Yes. If you already use an AI service (OpenAI, Claude, Gemini, or any provider with an API), it can be connected to your CRM or custom software to summarize notes, draft emails and replies, or answer questions about your records. You keep your own account and pay the provider directly for usage, and nothing it suggests changes your data until someone on your team approves it. Adding it runs $2,500–$6,000.
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. You get an API documentation review, the constraints it turns up, and a fixed scope and price before any code is written.
Get a quote