Operation Accounting
Operation accounting describes when Gateman counts a capability invocation against an account's included operation allowance.
What counts as an operation
Gateman meters explicitly classified billable capability operations. It does not meter every HTTP request.
One accepted invocation consumes one operation when it enters the accounting lifecycle for execution. A successful result is not required. This accounting unit is separate from provider fees, payment transaction amounts, subscription charges, raw HTTP request counts, provider delivery success, and Gateman's internal database or KMS calls. A capability may make multiple internal provider requests without consuming multiple Gateman operations.
Billable capabilities
Each accepted invocation of the following capabilities consumes one operation, whether it succeeds or fails after acceptance. Availability can depend on the account, application scopes, provider configuration, and environment.
| Capability | Operation type |
|---|---|
| Custom and managed secret retrieval | secrets.get |
| Database password retrieval | database_password.get |
| Stripe relay | stripe.request |
| Square relay | square.request |
| PayPal relay | paypal.request |
| Stripe webhook secret retrieval | stripe.webhook_secret.read |
| Stripe webhook setup | stripe.webhook.setup |
| S3 presigning | s3.presign |
| Cloudflare R2 presigning | r2.presign |
| Turnstile credential retrieval | turnstile.credentials.get |
| reCAPTCHA credential retrieval | recaptcha.credentials.get |
| SES, Postmark, and Resend email sending | email.send |
| Twilio SMS sending | twilio.sms.send |
| Telnyx SMS sending | telnyx.sms.send |
| AWS SMS sending | aws.sms.send |
See the individual capability references for request fields, scopes, provider behavior, and provider-specific responses.
Requests that do not consume an operation
Examples of non-billable requests include:
/health/config/get/email/readiness/client/get- official client download routes
- webhook ingestion routes
- rejected authentication attempts
- requests rejected during validation before reservation
- pre-reservation concurrency rejection
- rejected credential-request replays
- hard-limit rejection
Non-billable does not mean unauthenticated, unrestricted, or unlimited. These routes can have their own authorization, rate, concurrency, or provider controls.
A billable route rejected before its operation is reserved is also non-consuming. HTTP status alone does not determine whether an operation was consumed.
Failed and indeterminate operations
Once Gateman accepts a billable operation for execution, it consumes one unit even if the attempt fails. This includes provider HTTP rejection or rate limiting after reservation, provider timeout, provider network failure, missing or invalid credentials discovered after reservation, credential decryption failure, internal capability errors, and indeterminate provider acceptance.
An accepted operation remains counted if execution terminates unexpectedly or its final outcome is unknown. An unknown outcome does not establish that the underlying provider accepted or rejected the request. It does not make the accepted Gateman operation free, and it must not be blindly retried. See Errors and responses for response handling.
Some failures occur before reservation, such as authentication failure, invalid request data, missing scope, credential-request replay, or hard-limit rejection. Those failures do not consume an operation.
Idempotency and retries
Request signing, credential-request replay protection, capability-specific idempotency, and operation accounting are separate controls.
- Contract v1 signing does not provide universal request idempotency.
/secrets/getand/db/getuse single-use credential-request identifiers. A rejected replay does not consume a second operation.- Email and SMS provide optional, capability-specific idempotency. A replay with an active retained key can return the retained result without another operation.
- Reusing an idempotency key with a conflicting payload produces a conflict.
- A new request without applicable idempotency protection can consume another operation.
- Stripe, Square, and PayPal relays do not use a universal Gateman idempotency mechanism.
Do not assume that an idempotency key is accepted or interpreted by every route. Follow the selected capability's contract, and do not blindly retry an uncertain provider outcome.
Account allowances
The included allowance belongs to the account and is shared across its applications. Usage is counted in the applicable accounting period. Trial, subscription, and custom entitlements determine the allowance; this page does not define pricing, rollover, or additional purchase policies.
Ordinary accounts have hard allowance enforcement. When the allowance is exhausted, further billable operations are rejected before reservation and do not consume another unit. Staging and development billable operations use the same accounting rule as production; local capture does not create a separate free allowance.
For the exact environment behavior of a capability, see Environments. For authentication and admission order, see Authentication and Contract v1.
Usage visibility
The customer console displays the current accounting period, used operations, included allowance, percentage consumed, and usage by application. Used operations are finalised consumed operations, not every HTTP request.
The console does not provide a customer-facing per-operation transaction ledger or request-ID search.