Standing service integrate-keep-named-integrations-healthy · revised 11 October 2026
Standing service
Keep up to three third-party integrations healthy: credentials, quotas and deprecations
Each month we check your named integrations for expiring credentials, quota use and announced provider changes, fix what sits in your code and tell you what only you can renew.
This starts a conversation by email. Nothing is charged, and nothing is reviewed, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Integrations fail on the provider's schedule, not yours: a refresh token lapses, a key reaches its review date, a quota is outgrown, an older API is marked legacy or a scope is retired. Each is announced somewhere, but nobody reads those notices against the code that uses them, so the first sign is a broken feature. The fault is that no one owns the watching.
Who it’s for: A founder or small engineering team whose product depends on a few third-party services, such as email, SMS, maps, calendar or chat, and who find out an integration is broken only when a customer complains.
Usually starts when: An integration stopped silently because a token lapsed, a quota was reached or a provider retired an endpoint, and nobody owned the question of what else might be next.
The result: The integrations you name stay working. Each month you see the credentials and review dates that are coming due, how close each integration is to its limits, the provider notices that affect it, and the result of an end-to-end staging check. Problems inside your code arrive as pull requests, and anything only you can renew is explained with the steps.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target is agreed in writing before it starts, set to what a service at this stage can actually keep.
Hours are agreed in writing before the service starts. At launch the service is not staffed round the clock, so we do not offer round-the-clock cover.
What must remain true
- Each named integration is listed in the register with its credential type, owner and any review or expiry date that can be seen
- No visible credential or consent date reaches you as a surprise: you are told at least thirty days before a date we can see
- Usage of each integration stays under an agreed share of its published limits, or the rise is reported before it is reached
- Provider notices that name something your integration uses are found, dated and answered with a fix pull request or a decision for you
- A monthly staging check of each integration passes, or the failure is investigated
What we watch
- The register and the read-only exports or screenshots you share each month
- The providers' public changelogs, deprecation pages and documentation
- Your application logs with personal data removed
- The result of the monthly staging check with the test credentials you provide
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A credential, token or consent setting in the register shows a review or expiry date within thirty days. | We tell you the date, the integration it affects and the exact steps for you to renew it. We do not renew it. |
| Shared usage figures pass the agreed share of a limit, or logs show repeated rate-limit responses. | We show you the figures and, where the cause is the client's retry behaviour, open a pull request that fixes it, or explain that the plan is the constraint. Priced as: API client retry and backoff fix |
| A provider notice names a version, endpoint, scope or feature the integration uses, with a date. | We check the code, open a fix pull request for a change inside the integration, or give you the decision and the date. |
| The monthly staging check fails. | We investigate, fix what sits in the code, or explain what outside the code changed. |
| A month ends. | We send a short written summary: register changes, dates coming due, usage, notices found and what is open. |
We do on our own
- Read provider documentation, changelogs and the exports you share
- Run the staging check with test credentials you provide
- Open pull requests on a branch or fork that change integration code and tests
- Update the register
We ask you first
- Anything that renews, rotates or creates a credential, or changes production
- Paying provider fees, changing a plan or contacting a provider for you
- Merging, or any change to your default branch
We escalate to you when
- A credential has already lapsed or been revoked
- A provider retires something within sixty days and the fix is outside the agreed scope
- Usage jumps in a way that could mean a leaked or abused credential, in which case we tell you to rotate it straight away
- Fixes pass the agreed monthly number
How you know it held. Each month you get the register, the dates coming due, the usage figures you provided, the notices found with their outcome and the staging check result, and you can compare them with your own provider dashboards.
How we keep it true
This service is never finished. Each month's summary shows what was checked and what is open, and it continues until you end it.
Make one API client survive rate limits and outages without duplicates or retry storms Job Each time it fires
One named API client in your code waits as the provider asks, backs off with spread-out retries, stops at a budget and never repeats a write that may already have happened.
As needed, within the agreed number
When repeated rate-limit responses come from one client's retry behaviour, the same fix can be bought on its own.
What is included, and what is not
- The integration register, kept up to date
- A fix pull request for each problem inside your code that we can fix, up to the agreed number a month
- Step-by-step instructions for each renewal or provider setting that only you can change
- A written monthly summary
Included
- Up to three named integrations on one product, each with its provider, credential type, owner and the calls it makes recorded in a short register
- A monthly review of the credentials and consent settings you can show, listing dates that are visible and flagging those whose expiry cannot be seen
- A monthly comparison of the usage figures you share against each provider's published limits
- A monthly read of the providers' public changelogs and deprecation notices for items naming what your integration uses
- A monthly end-to-end check of each integration on staging using test credentials you provide, and a written summary
Not included
- Renewing, rotating or creating credentials, which stay with your account holder
- Merging, deploying or changing production
- Paying provider fees, changing plans or contacting a provider's support for you
- Building a new integration or rewriting an old one: those are separate outcomes
- Out-of-hours cover or any guaranteed response time
- Security monitoring, incident response or compliance assessment
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Within the first month, the register lists every named integration with its provider, credential type, owner and any visible review date, and you confirm it matches your own records.
Evidence: The register and your written confirmation or corrections.
Each month's summary lists the dates coming due, the usage compared with limits, every provider notice found for the named integrations and the staging check result for each.
Evidence: The written monthly summary, which you can compare with your own provider dashboards.
For each problem inside your code that we fix, the staging check for that integration passes on the pull request branch and no unrelated file changes.
Evidence: Links to the passing check and the pull request diff.
Sign-off. You read each monthly summary and review and merge each pull request. A fix counts as delivered when you accept it.
If it fails. If we cannot fix a problem we say so, explain what we found and what it would take, and it does not count against the monthly number. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- The integrations are ones your code already uses, and you can name the provider and the part of the code that calls it
- You can share, for each, a read-only view of credential review dates and usage, for example as screenshots or exports with secrets removed
- A staging environment and test credentials exist for each integration, or you accept a partial check
- A person on your side reviews and merges pull requests and renews credentials
We stop and tell you if
- Most of the integrations can only be tested with production credentials we would have to hold
- The register shows more than three integrations or an integration with no clear owner, so we agree a different scope
- Problems mostly sit with credentials or plans that you cannot or will not renew
- Fixes regularly exceed the agreed monthly number
What could go wrong
Every code change is a pull request that your team merges, so any one can be reverted like any other change. Ending the service leaves the code as it is, with the register handed over and open pull requests finished or handed back.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A credential expires between monthly checks. | We flag every visible date at least thirty days ahead and say plainly which credentials show no date; the service does not claim to see what the provider does not show. |
| A provider notice is missed because it is published outside the places we read. | The register names the sources read for each provider, and you are told when a provider has no public notice channel. |
| Test credentials or screenshots expose a secret. | We ask for exports with secrets removed and use only staging credentials you create; production secrets are never shared. |
Each pull request is checked by a reviewer separate from the work that produced it before it is opened. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You review and merge every pull request
- You renew, rotate and create every credential
- You approve any change to production or plans
Access we would need
- Read access to the code and a branch or fork for pull requests
- Read-only exports or screenshots with secrets removed
- Test credentials for staging that you create
Questions
Will you renew our credentials?
No. Renewing and rotating stay with you. We tell you what is coming due, which integration it affects and the exact steps.
What if a credential shows no expiry date?
We say so in the register and rely on the staging check and the provider's documented lifetimes, but we cannot promise to see what the provider does not show.
How is this different from buying one fix?
A fix repairs one problem once. This is a standing responsibility: we watch the named integrations and carry each issue to a pull request or an explanation, month after month.
Can we add a fourth integration?
Not within this scope. A larger set is quoted separately.
Also part of
Send an enquiry
Send us
- The names of the integrations and what each is used for
- The language and framework, and where each integration's code lives
- Who currently renews credentials, if anyone
- Do not send API keys, tokens, customer data or code in the first enquiry
Later, once you agree
- Read access to the code through a company-controlled repository, with a branch or fork for pull requests
- Read-only exports or screenshots of credential lists and usage dashboards, with secrets removed, each month
- Test credentials for staging, created and held by you
- The agreed number of fixes a month and the person to tell about renewals
You own every account, credential and token. We read the code and what you share, change files only on a branch or fork through pull requests you review, and never hold production secrets.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “integrate-keep-named-integrations-healthy” as the subject.