# The parts we don't run

> See what happens when your app calls or loads a service another company runs. Four kinds, where each connects, and what to do when one breaks.

Source: https://customhosted.com/outside-services/

№ 01 Outside services

Your app leans on services somebody else runs. Here is the line, and what we do on our side of it.

№ 02 Four kinds

## What counts as an outside service

A category named each time, never a product.

- Called from your server — Your own code makes a request out, and waits for an answer before it replies to the visitor. — Charging a card, sending a text, looking up an address.
- Loaded by the browser — The visitor's browser fetches it directly — no server of yours sits in between. — A map, a chat widget, a measurement tag.
- Calls you back — The far end posts to your app on its own schedule, once something happens on its side. — A payment clearing, a message being delivered — the webhook case.
- Holds your data — A record lives there permanently, not just passed through on a single call. — A support desk, a mailing list, a customer record store.

№ 03 Where it connects

## One call, hop by hop

The same path whichever kind of service sits on the other end.

1. 1 — Your code makes the call — The same way any outbound request leaves an app — a plain call to an address somewhere else.
2. 2 — The key is read from the config store — Sent once, at onboarding or whenever it changes, and kept in an encrypted store — never copied into a spreadsheet, a chat message, or a second system to keep in sync.
3. 3 — The call leaves the instance — It travels out to the far end's own server, wherever that happens to be.
4. 4 — The response comes back — Success, an error, or nothing at all.
5. 5 — A timeout, if it never answers — Your own code has to decide how long to wait before giving up and trying something else.

№ 04 By hosting shape

## What changes depending on where your app runs

A static site has no server to hold a secret in. A dedicated instance has a static IP to hand an allowlist.

- ST-STARTER — Static Starter — No standing server, so nothing here can hold a secret at all. A call to an outside service has to run from the visitor's own browser, out in the open. That's fine for a map or a widget. Never for a payment key.
- DD-M — Dedicated M — A standing process makes the call from the server side. Every instance ships with its own static IP. That's exactly what a payment or banking API wants for an allowlist.
- CU-0 — Custom — Whatever mix of browser-side and server-side calls the design needs, sized and confirmed once, at the quote stage.

№ 05 On the staging copy

## A sandbox key, not the live one

Reused whole from Environments — never a second wording of the same rule.

- Third-party integrations rarely behave the same way twice — A payment gateway or a customer-messaging tool usually needs its own sandbox mode, or isn't wired into staging at all — check per integration rather than assuming.
- Outbound mail and messaging are pointed at a sink or disabled — The classic staging mistake is a test run that emails or texts real customers. Anything a staging copy would otherwise send outward is caught or turned off, not delivered.

№ 06 Four ways one breaks

## Named plainly, with a route out for each

A signal, who sees it first, and where the fix actually happens.

- It stops answering — Signal — Every call to it times out, or comes back with an error. First seen by — Us, on the error-rate signal already on the watch list. Route out — Escalated the same way any other fault is. See [Monitoring](https://customhosted.com/monitoring).
- It gets slow, and drags your page down with it — Signal — Your own page holds open while the call runs. The visitor waits on a server nobody here controls. First seen by — A visitor, usually before anything on our side sees it. Route out — Brief it out, or brief a lighter one in its place. The change is reviewed and shipped the same way as any other. See [Performance](https://customhosted.com/performance).
- It changes its API on a deadline — Signal — An email from the provider, not a signal anything here can watch for. First seen by — You — nothing on our side reads a provider's own changelog. Route out — Brief the change once the deadline is known. See When one forces a change.
- Its key expires, or gets revoked — Signal — Calls start failing with an authorisation error, not a timeout. First seen by — Whichever side reads the failure first. Route out — Send the replacement value whenever you choose — there is no console click, only the same quote channel as any other change. See [Access — secrets](https://customhosted.com/access).

№ 07 Who owns what

## Five scattered lines, one table

Every row is quoted from the page that already owns the fact, never reworded here.

| Page | What it already says |
| --- | --- |
| [Monitoring](https://customhosted.com/monitoring) | Anything living in a service we don’t run watches itself on its own schedule, not ours. |
| [Incidents](https://customhosted.com/incidents) | A dependency living in a service we do not run goes down on its own schedule, not ours. |
| [Environments](https://customhosted.com/environments) | A payment gateway or a customer-messaging tool usually needs its own sandbox mode, or isn't wired into staging at all — check per integration rather than assuming. |
| [Recovery](https://customhosted.com/recovery) | Anything living in a service we don't run — a payment processor, an email platform, an analytics tool — backs up on that service's own schedule, not ours. |
| [Performance](https://customhosted.com/performance) | A widget, a tracking pixel, or an embed is a request to a server we do not run. No page-weight budget of ours can cap what it costs a visitor. |

№ 08 Worked artifact

## This site's own dependency count

Read from this build's own measured page weight, never typed by hand.

1

outside host this site itself loads, measured straight from the build behind Performance. `check:perf` reads the shipped site on every deploy. A second host fails the build until someone adds it to the allowlist on purpose.

№ 09 When one forces a change

## A deadline email becomes a shipped change

The same pipeline that ships every other change ships this one too.

A forced API change travels the same path as any other briefed change — the one Patching already walks through for a flagged dependency:

1. 1 — A routine scan flags a dependency — The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list. — CustomHosted
2. 2 — It's triaged as application-level, not infrastructure — A library your own code imports isn't ours to patch silently — it can change how the app behaves. — CustomHosted
3. 3 — Briefed as a change — Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers. — CustomLabs
4. 4 — An agent opens the pull request — The upgrade lands as a real pull request against the repository, with the test suite run against it. — CodeHerder
5. 5 — A human reviews and merges — Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind. — CustomLabs
6. 6 — It ships through the same pipeline — The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit. — CustomHosted
7. 7 — You're told it's done — A note confirming what changed and that it merged, in the same shape as every other note on this site. — CustomHosted

№ 10 What it costs

## No separate integrations line

The same allowances as any other change, priced once and reused here.

- Wiring in a new outside service is a briefed change — Adding a call, a webhook, or a widget is a briefed change, the same as any other. It goes through the Agentic iteration — CodeHerder add-on ($25/mo). Brief a change in plain words. An agent opens a pull request, a person reviews it, and the same pipeline ships it.
- It draws from the same iteration allowance — 3 changes a month, 2 hours each. That's the same allowance a config change or a new integration draws from.
- Outbound traffic counts toward transfer — Every call out and every reply back is transfer, the same as any other request. Static Starter: ~100 GB transfer/mo. Static Pro: ~500 GB transfer/mo.

№ 11 Said plainly

## The honest limits

No named vendor, no uptime figure for a service we do not run.

- Third-party services aren't watched by us — Anything living in a service we don’t run watches itself on its own schedule, not ours.
- Third-party outages, we cannot fix — A dependency living in a service we do not run goes down on its own schedule, not ours.
- Third-party integrations rarely behave the same way twice — A payment gateway or a customer-messaging tool usually needs its own sandbox mode, or isn't wired into staging at all — check per integration rather than assuming.
- Data held in a third-party service — Anything living in a service we don't run — a payment processor, an email platform, an analytics tool — backs up on that service's own schedule, not ours.
- No uptime number for a service we do not run — We publish our own 99.9% target because we can measure it. Nobody here holds an uptime figure for a service we don't run or control.
- No named vendor — This page never names a vendor. It describes a category only: a payment provider, a mail sender, a customer-messaging tool.

№ 12 Answers

## Outside-services questions

What people ask once "is that on your side or theirs?" needs a real answer.

1. 01 My app takes card payments and sends texts. What happens when one of those breaks? It depends on which of the four ways it breaks — see the table above. Most of the time it is your provider's own outage. It clears on its own schedule, not ours. If it's a code change on your side, it goes through the same briefed pipeline as any other fix.
2. 02 Do you monitor the third-party services my app calls? Anything living in a service we don’t run watches itself on its own schedule, not ours.
3. 03 Can a dedicated instance give my payment provider a static IP to allowlist? Yes. Dedicated M and every other dedicated tier ships with its own static IP by default. See "By hosting shape" above.
4. 04 Can a static site hold an API key safely? No. A static site has no standing server, so a key baked into it ships to every visitor's browser. See Configuration for the build-time-versus-run-time rule in full.
5. 05 What happens to a webhook or an outside call on the staging copy? A payment gateway or a customer-messaging tool usually needs its own sandbox mode, or isn't wired into staging at all — check per integration rather than assuming. The classic staging mistake is a test run that emails or texts real customers. Anything a staging copy would otherwise send outward is caught or turned off, not delivered.
6. 06 A provider is retiring the API my app calls. What do we do? Brief it as soon as the deadline is known. An agent opens the pull request against the new API. The checks run, then a human reviews it. The same pipeline ships it — see "When one forces a change" above.
7. 07 Does an outside call cost extra? Not on its own. Wiring one in is a briefed change, under the same iteration allowance as any other small change. The traffic it generates counts toward the plan's transfer allowance, like any other request. See "What it costs" above.
8. 08 Do you back up data held in a service you do not run? Anything living in a service we don't run — a payment processor, an email platform, an analytics tool — backs up on that service's own schedule, not ours.

№ 13 Keep reading

## What outside services connects to

- [Your data Each call this page names is a place personal data can go — this page's own shape rows, reused whole.](https://customhosted.com/your-data)
- [Logins An identity provider is one of these — what a login needs from it, and what happens when it is down.](https://customhosted.com/logins)
- [Configuration Where the key itself lives — a setting against a secret, and the build-time-versus-run-time trap this page's "by hosting shape" section leans on.](https://customhosted.com/configuration)
- [Monitoring The watch list this page's "it stops answering" row escalates through, and the honest line on what it does not cover.](https://customhosted.com/monitoring)
- [Incidents What happens once a failure is confirmed — the first-hour timeline this page's escalation row points at.](https://customhosted.com/incidents)
- [Recovery What a backup actually covers, and why data held somewhere else backs up on its own schedule.](https://customhosted.com/recovery)
- [Performance The measured page-weight budget an embedded tag counts against, and this site's own one-host worked artifact in full.](https://customhosted.com/performance)
- [Access The rotation cases this page's "key expires" row reuses — a leak, a departure, and a scheduled change.](https://customhosted.com/access)
- [Under attack The perimeter between junk traffic and your app — the layer in front of every call this page describes.](https://customhosted.com/under-attack)

## Wiring in a new outside service, or dropping one?

Brief it through the same quote channel as any other change — see Billing for how the number is priced.

[Get a quote →](https://customhosted.com/contact)