The parts we don't run

• 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.

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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

• 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.

• 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.

1. 01My 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. 02Do 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. 03Can 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. 04Can 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. 05What 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. 06A 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. 07Does 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. 08Do 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.