Faximus API and Webhook Fair Use Policy

Version: 2026.10.27-r1

This policy applies when Customer uses a Faximus API, SDK, machine credential, callback, webhook, or other programmatic interface. It is part of the Faximus Terms of Service and supplements the Acceptable Use Policy.

Where a feature is not enabled for Customer's plan or account, this policy does not require Faximus to provide it.

1. Use documented interfaces

Use only the APIs, methods, fields, authentication schemes, endpoints, and versions described in current Faximus documentation or expressly provided to you in writing.

Do not scrape the portal, automate browser sessions, call internal endpoints, imitate an operator session, discover hidden routes, or rely on undocumented behavior. Faximus may change undocumented behavior without notice.

2. Credentials and authorization

2.1 Keep credentials secret

API keys, tokens, client secrets, signing secrets, and similar credentials are confidential. Store them in a secrets manager or comparably protected system. Do not place them in source code, browser code, mobile applications, shared documents, logs, screenshots, support tickets, or public repositories.

2.2 Least privilege and separation

Use the narrowest scopes available. Use separate credentials for production and non-production, for materially different integrations, and for separate customers or tenants. Do not reuse one Customer's credential to submit another Customer's traffic.

2.3 Rotation and compromise

Rotate credentials on a reasonable schedule and immediately after suspected exposure. Faximus may revoke or rotate a credential that appears compromised, unused, abusive, or inconsistent with Customer's account.

3. Rate limits, concurrency, and fair use

3.1 Published limits

Customer must stay within the rate, concurrency, file-size, page, recipient, storage, number, and queue limits shown in its plan, order form, response headers, error messages, or documentation. Limits may differ by endpoint, account history, destination, carrier, number type, and environment.

A successful request does not guarantee immediate processing or delivery. Faximus may queue work to protect reliability and fair access.

3.2 Reasonable traffic design

Customer must:

• use pagination and filters rather than repeatedly downloading large collections;
• cache data when appropriate;
• use exponential backoff with jitter after a rate-limit, network, or temporary server response;
• honor a Retry-After header when provided;
• avoid synchronized polling across many jobs or accounts;
• avoid unnecessary status requests when webhooks or a bulk endpoint are available; and
• limit parallel uploads and fax submissions to a level appropriate for the plan.

3.3 Rate limiting and protective action

Faximus may return a rate-limit response, delay work, reduce concurrency, reject a file, or temporarily restrict an integration that causes instability, unusual cost, carrier risk, suspected fraud, or disproportionate load. Attempting to evade a limit through multiple accounts, credentials, IP addresses, destinations, or request variations violates this policy.

4. Idempotency, retries, and duplicate faxes

4.1 Use idempotency controls

For any endpoint that supports an idempotency key, use a unique, stable key for one intended operation and reuse that same key when retrying the identical operation. Do not reuse a key for a different document, recipient, or instruction.

Do not place PHI, recipient names, fax content, or other sensitive data in an idempotency key.

4.2 Retry carefully

A timeout or lost response does not necessarily mean the original request failed. Before submitting again, check the job by idempotency key, request identifier, or status endpoint when available.

Fax transmission protocols and carrier behavior can produce uncertain outcomes. Blind retries can create duplicate faxes. Customer is responsible for designing retry logic that considers the most recent known state and the risk of duplication.

4.3 Faximus retries

Faximus may retry a fax or webhook according to current documentation, account configuration, and operational judgment. A retry schedule is not guaranteed unless an order form expressly makes it a commitment. Retries may use a different carrier, media profile, route, or timing.

Unless the applicable pricing terms or order form expressly say otherwise, Faximus does not separately charge for Faximus-initiated automatic internal retries of the same submitted fax job. If Customer, Customer's software, or a third-party integration submits a new job after an error, timeout, or uncertain result, the new job may create new billable usage. Use idempotency keys where supported and check current status before resubmitting. A delivery or webhook status is not, by itself, the billing rule; billing is governed by the Terms of Sale.

5. Files and document processing

Customer must submit supported file types and remain within documented file-size and page limits. Faximus may render, normalize, rotate, compress, or convert a document for fax transmission. The rendered page count may differ from the source application's page count.

Customer must scan files for malware before submission and must not submit encrypted or password-protected files unless documentation expressly supports them. Faximus may reject a malformed, dangerous, unsupported, or unusually resource-intensive file.

Customer should preview or otherwise validate important documents before production use. Font substitution, page scaling, margins, color conversion, and image compression can affect appearance.

6. Webhook delivery model

6.1 Availability

Webhooks are available only where enabled for Customer's plan and event type. Faximus may offer some events through polling, the portal, or an API before offering them by webhook.

6.2 At-least-once, not exactly-once

Unless documentation expressly says otherwise, Customer must treat webhook delivery as at least once. Events may be delayed, duplicated, retried, or delivered out of order. Faximus does not promise exactly-once delivery.

A webhook is an operational notification. It is not the authoritative legal proof that a fax was delivered, received, read, filed, or acted upon. When accuracy matters, query the current job or fax record through the API or portal and follow the Fax Delivery Disclaimer.

6.3 Endpoint requirements

Customer's webhook endpoint must:

• use HTTPS with a valid, supported certificate;
• be controlled by Customer or an authorized processor;
• accept the documented HTTP method and content type;
• respond promptly with a documented success status after safely accepting the event;
• process events idempotently;
• validate schema and event type;
• protect against replay, injection, and server-side request forgery; and
• avoid redirect chains, interactive authentication, or responses containing sensitive data.

Faximus may reject private, loopback, link-local, metadata-service, or otherwise unsafe destinations.

6.4 Verify authenticity

When Faximus provides a signature, timestamp, secret, certificate, or other authenticity mechanism, Customer must verify it before trusting the event. Customer must rotate a compromised webhook secret and should reject stale or replayed messages according to the documentation.

IP allowlists alone are not a substitute for cryptographic verification because delivery infrastructure and addresses may change.

6.5 Retries and failure

If an endpoint times out, returns an error, rejects TLS, or otherwise fails, Faximus may retry according to the current retry schedule. Faximus may stop retrying after the documented window or after repeated permanent failures.

Customer must monitor endpoint health and should use the API or portal to reconcile missed events. A webhook failure does not mean the underlying fax failed, and a webhook success does not prove the fax was successfully received by the intended person.

6.6 Event retention and replay

Faximus may retain webhook attempts, headers, response codes, and limited payload data for the period in the Data Retention and Deletion Schedule. Event replay, manual redelivery, or a dead-letter view is available only where the product or plan expressly provides it.

7. Data minimization and privacy

7.1 Keep sensitive data out of metadata

Do not place sensitive content in URLs, query strings, callback URLs, API key names, idempotency keys, free-form tags, filenames, or diagnostic fields unless the documentation expressly identifies the field as suitable for that data.

7.2 Webhook payloads

Configure the least amount of webhook data needed. Customer is responsible for the security and legal compliance of its endpoint and downstream systems. If a webhook may contain PHI, Customer must have a signed BAA, use a HIPAA-enabled account, and ensure that the endpoint and every downstream processor are authorized and appropriately protected.

7.3 Logs and support

Redact secrets, document content, and unnecessary personal data before sharing logs with Faximus support. Faximus may reject or delete a support attachment that contains unnecessary sensitive data.

8. Test and production environments

Keep test and production credentials, endpoints, data, and automation separate. Use synthetic or de-identified data for testing whenever practical. A test or sandbox environment may have different behavior, routes, destinations, delivery simulation, limits, retention, or uptime and is not covered by a production SLA.

Do not assume that a sandbox success predicts carrier or recipient behavior in production.

9. API versions and changes

9.1 Backward compatibility

Faximus will use reasonable efforts to avoid breaking a generally available, documented API version during its supported life. Additive changes, new optional fields, new event types, new enum values, and changes that fix a security or legal issue are not considered breaking changes. Customer must write clients that ignore unknown fields and handle documented fallback values.

9.2 Deprecation

For a generally available API version, Faximus will use reasonable efforts to give at least 90 days' notice before a material breaking change or retirement. A shorter period may apply when required by law, security, carrier action, third-party dependency, or an emergency.

Beta, preview, compatibility, and undocumented interfaces may change without that notice.

9.3 Customer maintenance

Customer must keep its integration reasonably current, monitor deprecation notices, and test changes before a retirement date. Faximus is not responsible for a failure caused by Customer's continued use of an unsupported version.

10. Prohibited programmatic use

In addition to the AUP, Customer may not:

• probe or enumerate accounts, numbers, jobs, users, or identifiers;
• use the API to validate or enrich unlawfully obtained recipient lists;
• simulate user behavior to bypass plan or permission controls;
• use high-volume polling when a documented event or bulk method is available;
• submit intentionally malformed files or requests to consume resources;
• benchmark or publish non-public performance results in a misleading way;
• proxy or expose Faximus credentials to an unauthorized third party;
• use the Services to operate an unapproved resale or white-label platform; or
• copy or use API responses to build a competing fax service in breach of the Agreement.

11. Monitoring and enforcement

Faximus may collect request identifiers, timestamps, endpoints, response codes, latency, source addresses, account identifiers, usage measurements, and error details to operate, secure, meter, and improve the Services.

Faximus may contact Customer about unusual traffic and require a remediation plan, capacity review, plan change, destination review, or security change. Faximus may rate-limit or suspend an integration immediately when reasonably necessary to prevent harm.

12. Support and contact

For integration support, contact support@faximus.io and include the account identifier, environment, endpoint, request or event identifier, timestamp with time zone, and sanitized error details. Never send a live secret or an unredacted document unless Faximus specifically requests it through an approved secure channel.

Report suspected credential compromise or a vulnerability to security@faximus.io.