List your models on TrustedRouter.

Neurometric AI is live on TrustedRouter.

Neurometric AI is a featured provider partner in the TrustedRouter marketplace. Its integration publishes a machine-readable catalog and gives developers one place to inspect callable models, exact pricing, capabilities, and the documented data-handling boundary.

TrustedRouter refreshes the catalog, runs live canaries, and monitors route availability through the same provider contract used across the marketplace.

Tell us who operates the service.

Email providers@trustedrouter.com from your company domain. The application must identify the legal entity, responsible contacts, privacy terms, and service being offered.

Complete every section below. Use Unknown, Not applicable, or Available under NDA with an explanation instead of leaving blanks. Identify which claims apply to all routes and which apply only to named models, tiers, regions, or accounts. Date your answers and link to supporting evidence.

• Service and supply chain. Describe the tasks and modalities you serve, whether you operate the inference hardware or resell another service, and every downstream inference operator.
• Company identity. Legal name, brand or DBA, website, jurisdiction, entity type, and DUNS number.
• Company details. Registered address, operating address if different, business phone, company registration number, EIN or VAT ID, and DUNS number. Never send a personal tax identifier.
• Leadership. CEO name and title, authorized contract signer, and ownership or parent company where applicable.
• Primary contact. Name, title, company email, and direct business phone for the person responsible for the application.
• Operational contacts. Named technical, security and privacy, legal, billing, and incident-response contacts with titles, company email addresses, and phone numbers where available.
• Policies. Privacy policy, terms, DPA, subprocessor list, security or trust center, and compliance reports or certifications.
• Data handling and locations. Complete the privacy and inference-location questions below, including exceptions and downstream providers.
• Energy. Is the inference service powered by 100% renewable energy? Include the percentage, scope, reporting period, and evidence requested below.

Identify which company details and evidence links may appear on your public provider page. Named contacts, direct phone numbers, and non-public agreements are for onboarding review, not the public catalog.

Do not email an API key or any other credential. After the application is reviewed, TrustedRouter will arrange a separate secure handoff for a dedicated, revocable inference key.

State what happens to request data.

• Content and metadata. Give retention and deletion rules for prompts, outputs, uploaded files, prompt caches, logs, and backups separately. List retained operational metadata and its retention period.
• Training and exceptions. Cover your own service and all subprocessors, including abuse monitoring, human access, and opt-in or opt-out settings.
• Applicable ZDR terms. Link the inference-specific policy or provide the agreement for our account through an agreed secure channel. Identify covered models, tiers, regions, and required settings. No training is not the same as zero retention.
• Confidential inference. Supply verifier instructions, attestation endpoints, source and immutable releases, and expected measurements. Explain encryption-key binding, GPU and downstream verification, and whether operators can access workload memory or keys. SOC 2 or encryption in transit alone does not establish E2EE.

Where can each route actually run?

• All possible locations. List countries or broad cloud regions for each model and tier, including downstream hosts and failover destinations. A headquarters address is not an inference-location guarantee.
• Dynamic routing. Say whether placement can change per request or over time, and how customers are notified. If global or unknown, say so explicitly.
• Pinning and returned evidence. Document the exact region parameter and allowed values, whether failover stays within it, and the response field or header reporting the actual serving region. Say when either feature is unsupported.
• Data residency. Separately identify storage, logging, prompt-cache, and backup locations and link the applicable residency commitment.

Is your inference powered by 100% renewable energy?

Answer Yes, Partly, No, or Unknown. If partly, give the renewable electricity percentage. Cover the infrastructure that will serve TrustedRouter requests, not just your offices or a company-wide target.

Include inference GPUs and supporting datacenter electricity, every applicable facility and region, downstream providers, and failover capacity. Name any exclusions or routes whose energy mix is unknown.

Show the basis of the claim.

• Scope and date. Specify covered models, regions and operators, the reporting period, measurement method, and next review date.
• Procurement and matching. Distinguish on-site renewable generation, power purchase agreements (PPAs), renewable energy certificates (RECs) or Guarantees of Origin, and hourly versus annual matching.
• Evidence. Link a facility or electricity-supplier disclosure, sustainability report, or independent assurance covering the declared scope. Arrange secure review of non-public evidence.
• No substitutions. Carbon offsets, carbon-neutral claims, and future targets do not establish 100% renewable electricity. Report them separately. A provider declaration is not independently verified certification.

Describe the API without sending secrets.

• OpenAI-compatible base URL. One HTTPS base such as https://api.provider.com/v1.
• Authentication format. Describe bearer authentication and supported credential scopes without including a live key.
• Canonical catalog. Serve the exact response below from GET /v1/models.
• Chat inference. Serve OpenAI-compatible requests from POST /v1/chat/completions.
• Exact models and features. Identify revisions, quantization, licenses, context/output limits, and per-tier support for tools, reasoning, streaming, structured output, and modalities. Exclude third-party BYOK passthrough models that our inference key cannot serve.
• Usage and caching. Document actual billed input/output tokens, cache-read/write counters, reasoning-token accounting, and final streaming usage. Include cache eligibility, TTL, isolation, and any required request fields.
• Prices and billing. Provide exact rates and units, all cache and request charges, minimums, batch/priority/long-context differences, effective dates, currency and taxes. Include prepaid or postpaid terms, funding and production-entitlement requirements, and how usage reconciles to invoices. Describe non-token APIs separately; do not force their prices into token fields.
• Operational limits. Document rate limits, capacity tiers, timeout behavior, error contracts, maintenance notices, and support escalation.
• Production readiness. Include a status page, any offered SLA, request-ID and rate-limit headers, deprecation notice period and replacements, and a dated redacted provider-checker report. Confirm production access and enough test credit for the agreed probes.

Keys travel separately.

The marketplace application is non-secret business and technical information. Once accepted, create a dedicated production credential restricted to model discovery and inference.

• Use a revocable key created only for TrustedRouter.
• Exclude account administration, billing, user management, and key creation permissions.
• Deliver it only through the secure channel arranged during review.
• Never place the key in email, support tickets, documents, chat, source code, or the catalog response.

Copy this output exactly.

Do not design a custom catalog or pricing format. Return one unpaginated JSON document from GET /v1/models. Put capabilities, prices, lifecycle, model deadlines, regions, and overload semantics in the machine-readable response.

• Use exact decimal strings. Every price is USD per one million tokens. Use "0.50", never a JSON float.
• Use null when a cache rate does not apply. Do not omit required fields.
• Use lowercase stable IDs. The format is provider/model-name. Never recycle an ID for a different model.
• Use UTC timestamps. Lifecycle timestamps use RFC 3339, for example 2026-08-05T00:00:00Z.
• Use one row per billable tier. If rates or capabilities differ, publish a distinct stable model ID for that tier.
• Document task-specific endpoints. Add the optional documentation object with a plain-text description, input and output guidance, and one representative example. TrustedRouter renders it on the model page.
• Separate overload from account quota. Return 503 for temporary serving capacity, 429 for request rate limits, and a stable account-quota error code when TrustedRouter must provision more quota.
• Always send Retry-After. Fast, explicit backpressure lets TrustedRouter roll over immediately instead of letting requests hang.
• Publish model deadlines. First-token, completion, and stream-idle budgets are evaluated per model rather than with one global timeout.

Download the v2 JSON Schema. The v1 schema remains supported for existing integrations.

Tell callers exactly what to send.

For extraction, classification, retrieval, summarization, and other task endpoints, include this optional object on the model row. All five fields are required when the object is present. Values are bounded plain text; do not send HTML, credentials, or customer data.

• Description: one sentence explaining the task.
• Input and output: state the expected request content and response contract.
• Example: provide a minimal synthetic input and its exact representative output.

Run the conformance suite before you apply.

Run the TrustedRouter provider checker against the same production API base you plan to submit. It tests catalog discovery, advertised model callability, chat completions, streaming, usage, tool calls, errors, and first-token behavior against the contract expected by TrustedRouter's attested gateway translator.

The suite is open source under Apache-2.0 and works with any conformant serving stack.

• Tiers 1–4 are the conformance gate. A hard failure exits with status 1, so the checker works in CI.
• Credentials stay local. Use TR_PROVIDER_API_KEY to keep the key out of shell history. Reports recursively redact it.
• Checks make real requests. The model sweep and chat probes use real, billable completion calls. The default sweep is bounded to 25 advertised models.
• Keep the report. Attach the redacted JSON artifact to your application so failures can be reproduced quickly.

These two calls must work.

The catalog request must match the published schema. The chat request must return a normal OpenAI chat completion with nonzero token usage.

• HTTP 200 with Content-Type: application/json
• choices[0].message.content contains PONG
• usage.prompt_tokens, usage.completion_tokens, and usage.total_tokens are integers
• The response model identifies the model that actually ran

If your API cannot implement this contract, email the same address with the incompatibility. Do not invent a second format.

Contract v1 covers chat-capable models. Include embeddings, image generation, audio, or other APIs in the email and we will map them separately.

We verify before we list.

1. Validate authentication and retrieve the live model catalog.
2. Match model IDs to exact prices and supported capabilities.
3. Run non-streaming and streaming probes against representative models.
4. Publish provider and model pages only for callable routes.
5. Refresh availability and pricing automatically as your APIs change.

Help developers choose your routes.

• Data retention, training, and zero-retention policy links
• Confidential-compute or attestation documentation
• Serving regions and data-residency constraints
• Renewable electricity percentage, covered inference routes, and supporting evidence
• Rate limits, capacity tiers, and expected error contracts
• A machine-readable deprecation feed, or an operations contact