Systems integration

System integrations, and the terms after launch

We build the connections between your platforms. Before you sign, you get the terms for what happens after launch, in writing.

Get your integration scoped

Tell us which systems have to agree. We usually reply within 24 hours, and everything you share stays private.

How we handle what you send is set out in our privacy notice.

The four rungs, in order

  1. 1

    A spreadsheet and one person.

    Someone exports from one system and pastes into another. It works, it lives in one head, and an accountant we read about ran month-end that way.

  2. Why 2 waits for 1Ahead of the next rung because it costs nothing, starts today, and needs nothing bought or built first.
  3. 2

    A no-code connector.

    The paste job now fails quietly: duplicate callbacks, mismatched job states, retries that corrupt data, and runs that stall without an error. Finance finds it before monitoring does.

  4. Why 3 waits for 2Ahead of the next rung because it is cheap and anyone can build it.
  5. 3

    An integration platform.

    The enterprise tool arrives and becomes one of the larger line items, and it still routes anything non-trivial back into custom code.

  6. Why 4 waits for 3Ahead of the next rung because it is governed and someone else is accountable.
  7. 4

    A freelancer build.

    It works until a vendor changes an API version or a token expires. Then no documentation, no replay path, and credentials in an account nobody at your company controls.

Argue with the order if your climb was different. Most companies we meet took these rungs in this sequence.

a slow third-party call that looks like our integration's fault

The alternatives' own published starting prices, read on 30 August 2026. None is an Atyantik price.

Read the meter column, not the price column. Seven vendors, seven different units. That is why the spread runs past 1,600 times and still tells you little. Your own number moves on how many systems are in scope, how they publish their APIs, and your volume. Your job then sits in one of three shapes we publish. A scoped project, when the scope is defined. Dedicated Team, when scope evolves across months. Team-Formation On Demand, when the gap is a skill you cannot staff. Sign off an estimate and it holds. Nothing executes before you approve it.

Show the price table
The alternatives' own published starting prices, read on 30 August 2026. None is an Atyantik price.
AlternativeCost to startWhat it metersNot included
Make9 USD a monthCredits, one per module action, 5,000 includedHigher tiers quoted through sales.
Zapier29.99 USD a monthTasks, one per completed unit of work, 750 includedHigher tiers quoted through sales.
Hookdeck39 USD a monthEvents, 10,000 includedVolume above the tier.
Svix490 USD a monthMessages, rebilled every 64 KiB chunkEnterprise terms quoted through sales.
Integrate.io1,999 USD a monthA flat platform fee, unlimited volumeThe connectors you still build.
XRAY15,000 USD a monthRetained human timeAnything outside the retainer.
CeligoPublishes no figureEndpoints and flowsEvery figure quoted through sales.
AtyantikWe publish no priceNot applicableWe publish no rate, band or starting-at figure.

Sources: Make's pricing page, Zapier's pricing page, Hookdeck's pricing page, Svix's pricing page, Integrate.io's pricing page, XRAY's pricing page, Celigo's pricing page.

how we scope this as a fixed first phase

How the work actually runs

  1. Who you talk to

    A named lead, not an account manager.

    A core team works only on your project, and you speak to the lead software engineer. On request, a technical person joins within one business day for architecture and stack questions. Ask about the queue design Tuesday, meet the software engineer building it Wednesday.

  2. What gates a merge

    A senior software engineer reviews every change.

    We run GitFlow with unit tests, integration tests and CI/CD gating every merge. One person's real test was whether he could understand the code the firm writes. Specimen: A pull request that fails the pipeline never reaches your main branch.

  3. Write it down

    Documentation from day one.

    Every project starts with architecture and deployment documentation, CI/CD pipelines, a BRD, an SRS and change notes, and architecture decisions go into the TRS so its shape is explained years later. Specimen: why your webhook receiver, that is the endpoint another system calls the moment something happens on their side, sits apart from your order service is documented.

  4. Name the gap

    We tell you whether the bench exists today.

    We say whether the skill is on the bench today or we must recruit. We have declined work that would have benefited Atyantik and not the project. Specimen: A vertical we have never shipped gets a straight answer.

the stack we build every connector on reliable deploys once the connectors are live

How long each platform keeps trying, in hours.

Show data table
Automatic retry duration before the platform stops trying, in hours, taken from the published webhook documentation of each platform. A webhook is the call another system makes to yours the moment something happens on their side, which means you receive the event rather than asking for it. Every number here is the platform's own published statement about its own retries. Stripe retries for three days with exponential backoff in live mode. Square retries for a day. Shopify makes eight attempts across about four hours. GitHub publishes zero, in its own words: "GitHub does not automatically redeliver failed webhook deliveries." GitHub also expects a 2XX inside 10 seconds, and past that it counts the delivery as failed. Shopify deletes the webhook subscription after eight consecutive failures. A long outage removes your integration rather than degrading it, and nothing on your side reports an error. Stripe states that ordering is not guaranteed and that an endpoint might receive the same event twice.
Item Automatic retry duration before the platform gives up
Stripe 72 hours
Square 24 hours
Shopify 4 hours
GitHub 0 hours

GitHub's zero is a real published zero, not a missing figure.

Figure Automatic retry duration before the platform stops trying, in hours, taken from the published webhook documentation of each platform. A webhook is the call another system makes to yours the moment something happens on their side, which means you receive the event rather than asking for it. Every number here is the platform's own published statement about its own retries. Stripe retries for three days with exponential backoff in live mode. Square retries for a day. Shopify makes eight attempts across about four hours. GitHub publishes zero, in its own words: "GitHub does not automatically redeliver failed webhook deliveries." GitHub also expects a 2XX inside 10 seconds, and past that it counts the delivery as failed. Shopify deletes the webhook subscription after eight consecutive failures. A long outage removes your integration rather than degrading it, and nothing on your side reports an error. Stripe states that ordering is not guaranteed and that an endpoint might receive the same event twice. Stripe, Square, Shopify and GitHub developer documentation, read 30 August 2026.

Sources: Stripe's webhooks documentation, Square's webhooks overview, Shopify's HTTPS webhook subscription page, Shopify's webhook troubleshooting page, Shopify's webhooks overview, GitHub on handling failed webhook deliveries, GitHub's webhook best practices.

our Cloudflare and edge platform work

What breaks, and who answers

  • Something breaks and nobody answers.

    The target is acknowledgement by a named person, not resolution, and we do not commit to time-to-fix. There is no 24/7 rota and no paging.

    What we commit to

    Our published business hours are Monday to Friday, 10:00 to 19:00 IST. Inside them, under an Annual Maintenance Contract or a lean-mode arrangement, the P1 response target is four working hours.

  • A vendor changes an API and the bill arrives afterwards.

    We do not absorb a vendor-forced change. You see the cost and decide, after launch too, under either published structure: an Annual Maintenance Contract or a lean-mode arrangement for lighter ongoing support.

    What we commit to

    Every change becomes a change note with time, effort and cost before you approve it. Nothing in the build moves on a re-scope you have not signed.

  • The code and the credentials end up somewhere you do not control.

    If you do not have your own Git hosting, cloud accounts and storage, we provision them in your name rather than ours.

    What we commit to

    From Day 1 every line is your IP. Code sits in your own repositories and deployments run in your own cloud accounts throughout.

  • You move the work and are left with a black box.

    So far, no client has needed to use that runbook. It is an offboarding document, and it exists so that leaving stays a decision rather than a fight.

    What we commit to

    If you ever choose to move the work in-house or to another partner, we hand over a written runbook for the handover itself.

the AI-model APIs we integrate against most often

Get these terms for your systems

Send us the systems and what goes wrong today. We usually reply within 24 hours.

How we handle what you send is set out in our privacy notice.

Published minimum API version support window, in months.

Show data table
The minimum time each platform publishes that an API version keeps working, from its own developer documentation. Four of the seven platforms we checked publish a support window. Salesforce publishes a minimum of three years per version and at least a year of deprecation notice. It then answers a retired version with the 410:GONE error code, and it has already retired versions 21.0 through 30.0. Meta publishes at least 24 months. Shopify and Google Ads publish about 12. Stripe, Xero and HubSpot publish no support window at all, which is not the same as giving you none. Google Ads, Salesforce and HubSpot return an error on a retired version, so your monitoring sees it. Shopify falls forward to the oldest accessible version, and Meta defaults to the next oldest usable one. Both return a success from a version you did not ask for, and no error-rate dashboard moves.
Item Published minimum API version support window
Salesforce 36 months
Meta 24 months
Shopify 12 months
Google Ads 12 months

Equal bars do not mean equal work. A quarterly release train still puts an upgrade decision in front of you every few months.

Figure The minimum time each platform publishes that an API version keeps working, from its own developer documentation. Four of the seven platforms we checked publish a support window. Salesforce publishes a minimum of three years per version and at least a year of deprecation notice. It then answers a retired version with the 410:GONE error code, and it has already retired versions 21.0 through 30.0. Meta publishes at least 24 months. Shopify and Google Ads publish about 12. Stripe, Xero and HubSpot publish no support window at all, which is not the same as giving you none. Google Ads, Salesforce and HubSpot return an error on a retired version, so your monitoring sees it. Shopify falls forward to the oldest accessible version, and Meta defaults to the next oldest usable one. Both return a success from a version you did not ask for, and no error-rate dashboard moves. Salesforce, Meta, Shopify and Google Ads developer documentation, read 30 August 2026.

Sources: Salesforce's API end-of-life notice, Meta's Graph API versioning page, Shopify's API versioning page, Google Ads' sunset dates, Stripe's API versioning page, Xero's changelog, HubSpot's deprecated-API reference.

For your security reviewer

Forward this to whoever runs your vendor review. It opens with the answer that goes against us, because that is the one they look for first.

The Cloud Security Alliance publishes the Consensus Assessments Initiative Questionnaire, CAIQ v4. It maps to the Cloud Controls Matrix v4.1, composed of 197 control objectives across 17 domains. It is free to download.

Forward this part

Atyantik Technologies: security and data-access answers for an integration review

  • Certifications we hold Atyantik does not hold SOC 2, GDPR or HIPAA certifications. We build systems that pass your audits. Architecture decisions are documented in the TRS, so your compliance team can verify design intent. If you need a certified vendor, we say so upfront and refer you.
  • Confidentiality An NDA is in place from day one. Access runs through your own identity provider, which means you remove us in one place (SSO), and through secure repositories.
  • Where the code and credentials live Code sits in your repositories. Deployments run in your cloud accounts. From Day 1 the IP is yours.
  • What Shopify requires of any third party Shopify publishes that apps have no access to protected customer data by default, and that its API returns nothing from non-development stores until the app is approved. Level 1 carries nine named obligations, and Level 2 adds seven more.
  • What Google requires of any third party Google requires an app using restricted scopes to pass an annual security assessment, and to obtain a Letter of Assessment from a Google-designated third party.
  • What Stripe recommends for any third party Stripe states that a third party should get a restricted key granting only the access it needs, rather than the account's secret key.

The questionnaire your reviewer can use (opens in new tab)

One engagement, measured

  1. 5 to 1login platforms

    A multi-product platform group had accumulated five separate login systems. We consolidated them onto one identity layer built on Keycloak, with OAuth 2.0, user federation and centralised authentication.

    Check itAnonymised client engagement, figures in our case-study record.

  2. down 70%auth-related support tickets

    One identity source instead of five removed the whole class of ticket that came from separate accounts disagreeing with each other across the estate.

    Check itMeasured after consolidation on the same engagement.

  3. down 40%licence and development cost

    Four login systems stopped being licensed and stopped being maintained, so both the licence line and the development effort behind them went away.

    Check itMeasured on the same engagement.

  4. thousandsmonthly active users supported

    The consolidated identity layer now carries the whole group's active user base on a single system rather than spread across the five it replaced.

    Check itSame engagement, same period.

The number we point at is the 70%, which counts how much less anyone had to touch it afterwards. Most of our engagements continue past launch as ongoing maintenance and growth work, and our longest active partnership has run more than a decade. engagements that continue past launch as ongoing maintenance and growth work

Connector, or a build

Does anything break if two records arrive out of order, or if the same event is processed twice? If nothing breaks, the connector is the right answer and you do not need a firm.

  • Use a no-code connector.

    Choose this when

    Data moves one way, volume is low, and a duplicate costs nothing worse than a tidy-up. Zapier's free tier runs 100 tasks a month and Make's 1,000 credits.

    It costs you

    You accept the ceilings each tool publishes for itself, and each of the four publishes a different one.

  • Have us build it.

    Choose this when

    Money moves, or two systems have to stay in step with each other, or a run outlasts the ceiling the platform publishes.

    It costs you

    A funded design job with a named lead, a change note before every change, and an upgrade to budget for.

n8n publishes FIFO only for executions queued behind its concurrency limit. Zapier de-duplicates on the source record's id and needs your API to return reverse-chronological order. Make ships sequential processing as an opt-in setting, off by default. Microsoft's limits page says concurrency control may leave triggers un-run. None of the four publishes an end-to-end guarantee that events arrive in order and exactly once. Three of the four publish a partial answer rather than none. That is their own line, not a criticism from us. We have turned down engagements that would have been good for Atyantik and wrong for the project. If your flow sits inside that boundary, go and use the tool.

Sources: Zapier's pricing page, Zapier's deduplication documentation, Make's pricing page, Make's scenario settings, n8n's concurrency documentation, Microsoft Power Automate's limits page.

a first production release built around one integration

The questions people ask on the call

Six things usually saved for a first call, answered here, including the two where the answer goes against us.

How much will this cost, and why more than the freelancer quoted?
Atyantik publishes no price for an integration, because the number is decided by the job. The freelancer quote is usually lower and usually real for the build. It runs until a vendor changes an API version or a token expires, and then nobody understands it. What moves the number:
  • How many systems are in scope.
  • Whether each publishes a usable API.
  • Whether data moves one way or both sides must stay in step.
  • Your volume against the platform's published ceiling.
  • Whether those platforms retire API versions on a calendar.
Can you just do it for a fixed price?
That depends on whether the scope is shared and concrete, which is what a scoping phase is for. Atyantik will not commit to a shape before that scope exists. Nothing executes until you have approved the full scope. Shorter engagements exist for a clearly scoped pilot or fix-it work.
Who fixes it at 2am when orders stop coming through?
Nobody, and that is the straight answer.
  • Atyantik's published business hours are Monday to Friday, 10:00 to 19:00 IST. There is no 24/7 rota, no on-call and no paging.
  • Inside those hours, under either published post-launch structure, an Annual Maintenance Contract or a lean-mode arrangement, the published response target for a P1 is four working hours.
  • The target is acknowledgement by a named person who engages with the issue, not resolution.
  • Time to fix depends on what the issue turns out to be, and Atyantik does not commit to it.
  • If your business needs overnight cover, you need a partner who runs a rota.
What happens if we stop working with you? Do we own this?
You own it throughout.
  • From Day 1 the IP is yours, the code lives in your repositories, and deployments run in your cloud accounts.
  • If you do not have your own Git hosting, cloud accounts and storage, Atyantik provisions them in your name.
  • Every project starts with documentation: architecture, deployment, CI/CD pipelines, a BRD, an SRS and change notes.
  • If you ever choose to move the work in-house or to another partner, Atyantik hands over a written runbook for that handover.
  • So far, no client has needed to use that runbook.
Will this double-charge anyone?
That risk is real, and it starts with what the payment platforms publish.
  • Stripe states that a webhook endpoint might receive the same event more than once, and that ordering is not guaranteed.
  • Shopify publishes an X-Shopify-Webhook-Id header so a receiver can detect a duplicate and skip it.
  • Stripe tells integrators to treat a 500 as indeterminate, because the operation may or may not have taken effect.
  • Handling that is a design decision on every engagement, and at Atyantik those architecture decisions are documented in the TRS, the Technical Requirements Specification, so any software engineer reading the system later knows why it is shaped the way it is.
Why does it break whenever a vendor updates something, and who pays?
Because these platforms retire API versions on a published calendar.
  • Salesforce publishes a minimum of three years per API version and at least a year of notice. It then answers a retired version with the 410:GONE error code.
  • Meta publishes at least 24 months.
  • Shopify and Google Ads publish about 12 months.
  • Stripe, Xero and HubSpot publish no support window at all, which is not the same as giving you none.
  • Shopify and Meta fall forward silently rather than erroring, so error-rate monitoring shows nothing.
  • On who pays: at Atyantik a vendor-forced change becomes a change note with time, effort and cost laid out before you approve it, on both published post-launch structures. Atyantik does not absorb it.

Tell us which systems disagree

Describe the systems that have to agree with each other and what goes wrong today. We usually reply within 24 hours.

Two answers come back. Either a scope for the connection, or a note that a connector will do this and you should keep your money. We have sent the second one before.

Write it in your own words. The systems, roughly what has to move between them, and what broke last time are enough.

On request, a technical person joins within one business day to answer architecture and stack questions directly. No automated number arrives in your inbox.

Tirth Bodawala, Founder and Principal Software Engineer at Atyantik Technologies
Tirth BodawalaFounder and Principal Software Engineer
  • everything you share stays private
  • usually a reply within 24 hours
  • nothing open-ended

No spam and no sales sequence: one person reads this and replies.

How we handle what you send is set out in our privacy notice.