Inferon
FeaturesPricingFAQsBlog
Get Started

API Policy

Effective Date: July 25, 2026
Last Updated: July 25, 2026

This policy governs use of the Inferon API and developer tools. It forms part of our Terms of Service, and our Acceptable Use Policy applies in full to anything you generate through the API.

Index

  1. Access
  2. Authentication
  3. API Keys
  4. Workspace Scoping
  5. Rate Limits
  6. Quotas and Credits
  7. Abuse Detection
  8. Versioning
  9. Deprecation
  10. Webhooks
  11. SDKs
  12. Restrictions
  13. Support

1. Access

API access is available to accounts on eligible plans. We may require verification before granting access to higher limits.

You are responsible for everything done with your credentials, including by your own end users if you build on top of our API. If you expose our capabilities to your users, you must pass through equivalent restrictions to those in our Acceptable Use Policy.

2. Authentication

All API requests require authentication and must be made over HTTPS. Requests over plain HTTP are rejected.

Interactive clients authenticate with a bearer token issued by our identity provider:

Authorization: Bearer <token>

Server-to-server integrations authenticate with an API key. Unauthenticated requests to protected endpoints receive 401, and authenticated requests lacking permission for a resource receive 403.

3. API Keys

  • Keys are displayed once at creation. We store only a hash and cannot recover a lost key.
  • Keys can be revoked at any time, and revocation is immediate.
  • Keys are scoped to a single workspace.
  • Key usage is logged.

You must not embed keys in client-side code, mobile applications, browser extensions, or public repositories, and you must not share keys between organizations or resell access to them.

Rotate keys periodically and immediately on suspected exposure. If you discover an exposed key, revoke it first, then contact security@inferon.ai.

4. Workspace Scoping

API resources belong to a workspace. Requests operate within the workspace associated with the credential, and cannot read or modify resources belonging to another workspace.

Members of a workspace can see the assets and generation activity within it. Manage workspace membership accordingly.

5. Rate Limits

Rate limits protect service stability for everyone.

| Scope | Limit | | --- | --- | | Authenticated requests | 300 per minute | | Unauthenticated requests | 60 per minute | | Generation requests | 30 per minute | | Checkout and billing requests | 10 per minute |

Exceeding a limit returns 429 Too Many Requests. Back off and retry, ideally with exponential backoff and jitter rather than a fixed interval.

Limits are indicative of the current defaults and may differ by plan. We may adjust them to protect service stability, and we may apply lower limits temporarily to an account generating disproportionate load. Enterprise customers can negotiate higher limits.

Repeatedly hammering a rate-limited endpoint is itself a form of abuse and may result in suspension.

6. Quotas and Credits

Beyond request rate, usage is governed by credits and by plan limits on storage, file size, and concurrent generation jobs.

Credits are deducted when a generation is accepted for processing and restored when a generation fails due to an error on our side or an upstream provider failure. Credit costs vary by model and are documented in the product and in our Model Usage Policy.

Requests that would exceed your credit balance are rejected rather than queued.

7. Abuse Detection

We monitor API traffic for patterns that indicate abuse, including credential stuffing, key sharing, scraping, automated evasion of safety filters, and traffic consistent with a compromised key.

Where we detect abuse we may throttle the account, revoke keys, block traffic, or suspend access. Where we believe a key has been compromised, we may revoke it without notice to protect you, and we will tell you promptly.

8. Versioning

Breaking changes are introduced through new versions rather than by changing existing behaviour.

We consider the following non-breaking, and they may ship at any time:

  • Adding a new endpoint or a new optional request parameter
  • Adding a new field to a response
  • Adding a new value to an existing enumeration
  • Changing the wording of an error message
  • Fixing behaviour that contradicts documentation

Write clients that tolerate unknown response fields and unrecognized enum values.

9. Deprecation

When we deprecate an endpoint, parameter, or model, we aim to:

  • Announce it in the changelog and notify affected accounts by email
  • Provide at least 90 days' notice before removal for API surfaces, and 30 days' for individual models
  • Document the migration path
  • Continue to serve the deprecated surface throughout the notice period

Shorter timelines may be necessary where a change is required to address a security issue, a legal obligation, or the withdrawal of an upstream provider. In those cases we give as much notice as circumstances allow.

10. Webhooks

Where webhooks are available, we deliver events to an HTTPS endpoint you nominate.

  • Verify the signature on every request before acting on it.
  • Respond quickly with a 2xx. Do your processing asynchronously.
  • Expect retries with backoff on failure, and design your handler to be idempotent, since an event may be delivered more than once.
  • Endpoints that fail persistently may be disabled, and we will notify you.

11. SDKs

We publish client libraries to make integration easier. They are provided as-is and are versioned independently of the API.

Use a current version. We support the latest major version and provide security fixes for the previous one.

12. Restrictions

In addition to our Acceptable Use Policy, you must not:

  • Circumvent rate limits, quotas, or credit accounting, including by rotating accounts or keys
  • Create multiple accounts to obtain additional free credits
  • Resell raw API access, or present our Services as your own model, without a written agreement
  • Use the API or any Output to train or fine-tune a competing generative model
  • Cache or store Outputs in a way that circumvents credit accounting
  • Probe, scan, or load-test our infrastructure without written permission
  • Misrepresent your identity, use case, or traffic volume

13. Support

Documentation and the changelog are the fastest route to an answer. For anything else:

  • Integration questions: support@inferon.ai
  • Suspected key compromise: security@inferon.ai
  • Higher limits or enterprise terms: see Enterprise Terms