The words we use when
we scope your system.
Automation and API operations terms, defined plainly and with an example. If a proposal or a runbook of ours uses one of these, this is what it means.
Reliability
05Dead letter queue
A durable holding place for messages or records that could not be processed after their retries were exhausted, kept so they can be inspected and replayed rather than lost.
Exponential backoff
A retry strategy where the wait between attempts grows multiplicatively, usually doubling each time. It gives an overloaded system room to recover instead of adding load.
Idempotency
A property of an operation where performing it many times has the same effect as performing it once. It is what makes retrying a write operation safe.
Retry storm
A failure pattern where many clients retry at the same moment after an outage, generating a load spike that keeps the recovering system down.
Silent failure
A failure that produces no error and no alert, so the system reports success while the work it was supposed to do never happened.
Integration
02MCP tool
A capability exposed through the Model Context Protocol, described well enough that an AI agent can decide when to call it and how to shape the arguments.
Webhook
An HTTP callback that a provider sends to a URL you own when an event occurs, so you receive changes as they happen instead of polling for them.
API products
03API key
A secret string sent with each request that identifies the calling account. It is the simplest workable form of API authentication and the foundation for quotas, limits and billing.
Quota and credits
An allowance of usage attached to an account for a billing period. Credits are a unit of quota that lets different operations cost different amounts.
Rate limit
A cap on how fast a client may call an API, usually expressed as requests per second or per minute. It protects the service from one client consuming capacity meant for everyone.
Operations
02Observability
The property of a system that lets you work out what it is doing from the outside, using the signals it emits, without adding new instrumentation first.
Runbook
A document that tells whoever is on duty what to do when a specific thing goes wrong. It is organised around symptoms, not around architecture.