AI Model and API Platforms Can Now Send Referral Programs for Review

Companies that run AI model platforms and AI APIs can now send their referral, credit and partner programs to TechAmerica.ai for editorial review. That includes hosted model providers, inference platforms, model gateways and routers, and specialized APIs for speech, vision, embeddings and search.

We have no partnerships, sponsorships or affiliate approvals with any of these companies, and we do not publish credit codes or live offers. This page explains how developer programs in this sector usually work, what developers should check before relying on one and what our editors need from a platform that wants its program reviewed.

Who this call is for

The developer AI market includes several kinds of providers, and all are welcome to submit:

• Frontier and open-weight model providers selling access through an API
• Inference and hosting platforms that run open models on managed infrastructure
• Model gateways and routers that give developers one API across many models
• Specialized APIs for transcription, text-to-speech, image generation, embeddings, reranking or document parsing
• Developer tools whose paid plans are built mainly on metered model usage

Routing and gateway layers have become their own category, as our coverage of model routing for cost control and a model's adoption record on an AI gateway showed. Programs from those layers are in scope.

How AI API pricing shapes referral programs

AI APIs are usually priced by usage. Language models charge per token of input and output, often at different rates for each and at different rates by model. Speech APIs charge per minute or per character. Image APIs charge per image or per step. Batch processing, cached inputs and reserved capacity may carry different prices again.

Because every request has a real compute cost, referral rewards in this sector tend to be usage credits rather than cash. A credit is easy for the provider to budget and directly useful to a developer. It also ties the reward to trying the product, which is the point of the program.

Common program types

• Starter credits granted to new accounts to test the API
• Startup programs that grant larger credit packages to companies accepted through an accelerator, investor or application process
• Referral credits paid to an existing developer when someone they invite starts paying
• Partner programs for consultancies, integrators and software vendors that build on the platform and bring in customers
• Marketplace and reseller arrangements through cloud providers, where usage is billed through a cloud account
• Education and research credits for students, instructors and academic projects

Consumer programs often exclude the API

Developers should not assume that a consumer referral reward applies to API usage. As of October 2026, OpenAI's help center described a ChatGPT Free referral campaign whose rewards applied only to ChatGPT Free usage and explicitly not to Codex or the API. Providers that run both consumer and developer programs should spell out which products each covers.

Anthropic's help center, also as of October 2026, said some Claude guest passes shared by subscribers could earn the sharer usage credits once a recipient converted to a paid plan, with those credits expiring a year after issue. That is a subscription program rather than an API program, but it shows how credit rewards tied to conversion are spreading across AI products.

Terms developers should read closely

Credit programs look simple until a developer builds on them. These are the terms that matter most.

Expiry

Credits almost always expire, sometimes within weeks for starter grants and within a year or two for startup packages. A developer planning a launch should know whether credits will last through it. Programs should state expiry plainly and say whether it can be extended.

Model and feature coverage

Credits may apply to some models and not others, or exclude fine-tuning, reserved capacity, batch jobs or premium tiers. A program that grants credits but excludes the model a developer actually needs is less useful than it appears.

Rate limits

New accounts often face lower rate limits that rise with spend or account age. Credits do not always raise those limits. If a developer plans to test at scale, the rate limit may matter more than the credit balance.

Billing after credits run out

Many platforms require a payment method to activate credits, and usage continues at standard rates once credits are exhausted. Developers should set spending limits and alerts before running large jobs. Programs should explain how billing begins and how to cap spend.

Eligibility and stacking

Startup programs often require a company to be below a funding or revenue threshold, to be referred by a partner, or to have never received credits before. Many forbid stacking one credit program with another. Referral credits usually exclude self-referral and accounts belonging to the same organization.

Geography and export rules

AI platforms may not serve every country, and access may be restricted by sanctions, export controls or the provider's own policies. Programs should list where they are available and whether credits can be used from every supported region.

Referral attribution for developers

Developer referrals are harder to track than consumer ones. A developer may read a tutorial, clone a sample repository, create an account weeks later and only start paying after a prototype becomes a product. Programs should explain how long attribution lasts, whether it follows the referred organization or the individual account and whether usage through a cloud marketplace counts.

Referral credits paid only after the referred account reaches a spending threshold are common, and sensible, because they reward real adoption rather than sign-ups. If your program works that way, state the threshold and the period over which it must be reached.

Data, privacy and acceptable use

Developers send user data through AI APIs, sometimes including personal, financial or health information. A credit program does not change a platform's data terms, but trial and free accounts sometimes come with different defaults on data retention or use for model improvement. Programs should state whether credit-funded usage is handled under the same data terms as paid usage.

Applications built in regulated sectors carry their own obligations. A developer building a health or financial product may need specific contractual terms, data residency or retention controls that are available only on certain plans. A startup credit program that places developers on a tier without those terms should say so.

Acceptable use policies also matter. Credit programs attract people who want free compute for purposes a provider prohibits, from spam to scraping. Platforms typically reserve the right to revoke credits for policy violations and should make those rules visible at sign-up.

Disclosure for developer advocates and creators

Developer marketing relies on tutorials, sample apps, conference talks, newsletters and videos. When a creator receives free credits, early access to a model or payment to publish a tutorial, the FTC's Endorsement Guides treat that as a material connection that should be disclosed clearly. The FTC's guidance says even free products and early access count.

Benchmarks deserve particular care. A creator who publishes a model comparison after receiving credits from one provider should say so near the results, not only in a footnote. Providers should avoid paying for favorable benchmark placement without disclosure.

Performance claims made by providers themselves also face scrutiny. The FTC's Operation AI Comply sweep in 2024 targeted companies accused of making deceptive claims about what their AI could do. Program pages and partner materials should avoid capability claims that the provider would not stand behind in its own documentation.

Platforms should also be careful with comparisons in their own program materials. Claims that a model is faster, cheaper or more accurate than a rival should be backed by published methodology, and partner kits should not invite affiliates to make stronger claims than the company does.

Why platform choice is a strategic decision

Credits can make a platform look cheaper than it is. A startup that builds on one provider because of a generous credit package may find switching hard once credits end, especially if its prompts, evaluations and tooling are tuned to one model family. Industry leaders have warned about over-reliance on one vendor, as our report on a warning about depending on a single AI provider described.

That is not a reason to avoid credit programs. It is a reason to read them with the end in mind: what will this platform cost at production volume, and how portable is the work built on it? Gateways and routers partly address that question, which helps explain their growth.

A practical way to evaluate a credit offer

Developers comparing credit programs can work through a short sequence before signing up. It takes less time than migrating an application later.

1. Estimate your real usage. Run a representative sample of requests and measure input and output volume, then project it to your expected traffic.
2. Convert the credit into time. Divide the credit by your projected monthly cost to see how many months it actually covers at the model you need.
3. Check what is excluded. Confirm that your model, endpoints and features are covered and that the rate limits fit your test plan.
4. Read the data terms that apply to credit-funded usage, especially if you will send user data.
5. Price the day after. Work out what you will pay at standard rates once credits end, and compare that with at least one alternative.
6. Set guardrails. Configure spending caps, usage alerts and key rotation before you start.

This exercise often changes the picture. A smaller credit on a cheaper model can outlast a larger credit on an expensive one, and a platform with predictable pricing may matter more than the size of the welcome grant.

Open-weight models and hosting platforms

Hosting platforms that serve open-weight models add a twist. The same model may be available from several hosts at different prices and speeds, so referral and credit programs compete on infrastructure rather than on the model itself. Programs from these platforms should say which models are hosted, how pricing compares across sizes and whether dedicated deployments are covered by credits.

Warning signs in AI API programs

• Credit amounts with no stated expiry or model coverage
• Programs that require a card but do not explain when billing starts
• Third-party sellers offering API credits or keys, which most terms prohibit
• Startup credit offers from intermediaries that charge a fee for access
• No statement on data handling for credit-funded usage
• Referral rewards that cannot be traced to official terms

Shared or resold API keys are a security risk as well as a terms violation. Developers should create keys only in their own accounts and keep them out of public code.

Sending your program to TechAmerica.ai

Platforms can submit through our contact page. Please put "AI API referral program" in your message and include the following:

1. Company name, platform name and official website
2. Program type: starter credits, startup program, referral credits, partner, reseller or education
3. What each party receives, in credits or cash, with caps
4. Eligibility criteria, including funding stage, revenue, referral source or account age
5. Which models, endpoints and features credits cover, and any exclusions
6. Credit expiry and whether extensions are possible
7. How billing begins after credits and how developers can cap spend
8. Rate limit treatment for credit-funded accounts
9. Data handling for credit-funded usage and links to data terms
10. Eligible countries and any regional restrictions
11. Disclosure guidance for partners, advocates and creators
12. Links to the official program page and terms, plus a named contact

How we review

Editors read the official program page, terms and relevant documentation, then compare them with your submission. We may ask for clarification on model coverage, expiry or eligibility. We will not publish details we cannot confirm from official sources.

Submission does not guarantee coverage, placement or ranking, and payment has no role in our decisions. We may decline programs that are closed, available only through private negotiation or too unclear to explain. If we publish, the article is labeled as describing a company program, links to official sources and carries publication and update dates.

A published article will describe the program type, explain what developers receive and under what conditions, list eligibility and exclusions in plain terms and link to your documentation. It will not repeat performance claims we cannot verify, and it will not include credit codes.

Keeping it accurate

Model prices and credit terms change often, sometimes with each model release. Send updates through the contact page with a link to the new terms. If a program is paused or closed, tell us whether existing credits remain valid so we can say so.