When you estimate Gateman usage, count the capability actions your application asks Gateman to perform—not every HTTP call your application makes. Health checks, readiness lookups, and other nonbillable endpoints don't consume your operation allowance. Requests rejected before billable acceptance don't consume it either. A valid email send, credential retrieval, or provider request can use one operation even if Gateman or the provider cannot complete it successfully.
That distinction matters when you estimate an allowance, investigate a failed call, or design a retry. The practical rule is: Gateman counts an accepted billable capability operation when it enters execution. A request that fails before that point does not consume an operation. Once accepted, the operation remains counted if execution later fails or its result is uncertain.
An HTTP request and an operation are different things
An HTTP request is how your application talks to Gateman. An operation is a metered invocation of a capability that Gateman has accepted for execution. One request can be rejected before it becomes an operation, and a single accepted operation can involve several internal steps or provider calls without becoming several Gateman operations.
Gateman’s billable capabilities include email and SMS sending; secret and database-password retrieval; Stripe, Square, PayPal, AWS, and Cloudflare requests; Stripe webhook setup and secret retrieval; S3 and R2 presigning; and Turnstile or reCAPTCHA credential retrieval. Each accepted invocation uses one operation. The route-specific admission order varies by capability. Other endpoints—including health, readiness, public configuration, client discovery, and webhook ingestion—are not operation-metered.
Some failures happen after Gateman has done work
An operation can fail after acceptance because Gateman has already begun carrying it out. It may have validated or transformed capability data, looked up or decrypted a credential, checked a provider configuration, or started the provider request. The provider may then reject the request, Gateman may encounter a network or internal error, or a timeout may leave the outcome unknown.
Those failures still consume the accepted operation. The allowance measures accepted capability work, not only successful outcomes. For example, a Stripe relay request can pass Gateman’s request validation and provider-admission checks, be accepted for execution, and then receive an error from Stripe. That provider error does not reverse the Gateman operation.
The exact boundary depends on the capability. Gateman performs some checks before reservation and some work after it. For example, relays validate the request and obtain provider-bound admission before reservation. A malformed request rejected at that earlier stage is not counted. Secret retrieval validates its request and claims its single-use credential-request identifier before reservation; lookup or decryption failures after reservation are counted. Do not infer operation consumption from an HTTP status code alone.
Rejections before acceptance do not use an operation
Common examples include failed authentication, missing capability authorization, invalid input caught before reservation, an application concurrency rejection before reservation, and a request rejected because the account has reached its hard allowance limit. These requests may still receive an HTTP error and may be subject to other security or rate controls; they simply have not consumed a billable operation.
Premium email suppression is a useful example of meaningful Gateman work that still happens before billable acceptance. Gateman checks recipients in to, cc, and bcc against applicable suppression records before provider execution or nonproduction capture. If an address is suppressed, Gateman rejects the whole send with 400 Recipient suppressed. If the safety check is unavailable, it returns 503 Mail safety check unavailable. Neither result sends or captures the message, and neither consumes an operation. After the temporary safety-check failure, the unchanged request can be retried with the same email idempotency key.
| Scenario | Uses an operation? | Why |
|---|---|---|
| Invalid authentication or capability permission | No | The request is rejected before billable acceptance. |
| Invalid relay payload rejected by Gateman validation | No | Relay validation happens before reservation. |
| Premium email recipient is suppressed | No | Suppression screening rejects before provider/capture admission and reservation. |
| Account allowance is exhausted | No additional operation | Gateman rejects the invocation before reservation. |
| Accepted provider operation receives a provider error | Yes | The operation entered execution before the provider result arrived. |
| Accepted operation times out or has an uncertain outcome | Yes | An unknown outcome does not undo acceptance. |
| Development or staging email is accepted for local capture | Yes | Capture is the accepted email operation for that environment. |
| Exact retained email/SMS idempotency replay | No additional operation | Gateman returns the retained result instead of accepting another send. |
Retries depend on the capability
An idempotency key is not a universal “free retry” switch. Email and SMS have Gateman-managed idempotency: an exact duplicate within the retention window returns the retained result without another send or operation. A changed payload under the same key is rejected as a conflict. Email and SMS retain completed results for 15 minutes; after expiry, a newly accepted request can use another operation. In-progress or uncertain outcomes remain protected because a timeout does not prove that the provider did nothing.
Credential retrieval uses a different mechanism. /secrets/get and /db/get require a single-use credential-request identifier. Replaying it is rejected without a second operation, but the identifier may already have been consumed if a later step failed; a new attempt needs a fresh identifier and signature.
Provider relays do not have universal Gateman-side idempotency. Some can forward a provider-native idempotency field, but Gateman still counts each separately accepted relay invocation. A signed X-GM-Idempotency-Key by itself only binds that header to authentication; it does not make a route idempotent. For an uncertain provider outcome, check the capability guidance before retrying.
Your applications share the account allowance
The monthly operation allowance belongs to the account and is shared across its applications. If an account has two applications and a 100,000-operation allowance, both applications draw from the same 100,000. The allowance is not duplicated for each app. The exact limit depends on the active trial, subscription, or account entitlement; check the current plans and pricing for plan details.
Gateman reserves capacity when it accepts an operation, so concurrent requests cannot all pass by observing the same remaining unit. For ordinary accounts, once the shared allowance is exhausted, further billable operations are rejected before reservation until the next accounting period or an allowance change. No overage operation is silently accepted.
Development and staging use the same operation accounting as production. For example, an accepted email captured locally in development still uses an operation even though Gateman does not contact SES, Postmark, or Resend. The environment changes what a capability does, not whether an accepted billable invocation counts. See Environments for capability-specific behavior.
Estimate usage from application events
Start with the application events that call a billable Gateman capability. Estimate how often each event occurs in a typical month, then add the totals across all of your applications. Include accepted nonproduction sends and allow for provider failures, because accepted failures still use operations. Exclude requests that are rejected before acceptance and exact retained email/SMS replays.
Suppose an application sends 2,000 accepted booking-confirmation emails in a month, and a scheduled process starts 30 times, retrieving its database password once on each start. That's about 2,030 accepted operations, before other capability calls or failed accepted attempts. This is an estimate from your own workflow; Gateman’s console shows usage for the current accounting period and breaks it down by application.
The short version: not every HTTP request counts, and not every failed request is free. An operation counts when Gateman accepts that billable capability invocation into execution. Checks and rejection before that point do not consume the allowance; failure after acceptance does. See Operation Accounting, Idempotency, Rate Limits and Concurrency, and Errors and Responses for capability-specific details.