Provider connection help

A provider connection links your provider account to Millwork. For OpenRouter, you approve access in the browser. AWS Bedrock uses a short-term Bedrock API key by default, with STS as an advanced option. Other key-entry providers ask for their API key. Enter credentials on Millwork’s private setup page. Millwork never returns the saved credential. Keep the connection ID to inspect or update it. Your catalog lists models available to your organization. Check the connection, its test result, and the catalog when a model is missing. GET /v1/model-source-profiles tells you which providers you can connect.

​

Why is my provider or model missing?

millwork provider list separates providers you can connect now from saved connections. A provider mentioned in a setup example may not be offered to your organization. If it is absent, contact support with the provider name. A working provider key alone does not make a model available. If the provider is listed but no models appear after connecting, check its connection test, refresh its models and read the catalog again. Use millwork models list for models you can choose now. These reads do not start a paid run. Keep the account you intended; a gateway route and a direct provider connection are different choices.

​

What the connection test tells you

A connection test is not a run. Millwork charges the platform fee only when it accepts a live run. See Model access and billing.

​

Check a used or expired setup link

For CLI setup, inspect the same application before continuing. For a key replacement, use the printed rotation continuation with its original request key and handoff ID. The browser link and spending proposal have separate expiry times. Inspect the saved setup before requesting a new link. AWS credentials have a separate use deadline; a new browser link does not renew access. AWS setup explains API-key and STS renewal. For REST or SDK setup, use the handoff_intent_id you saved to read GET /v1/source-credential-handoffs/{handoffIntentId}.

​

The connection passed but a run failed

A connection test reads provider account or model information; it does not ask a model to answer. A live run also depends on the selected model, provider capacity and the task’s limits. Read the failed run’s status, events and receipt before sending another request. An SDK forwards these responses; a provider or routing failure does not by itself mean the SDK is broken.

• For authentication failure, check access or credential expiry on the existing connection. Use its replacement flow when needed.
• For a missing or unsupported model, check the exact catalog model and provider requested. Do not restart browser setup or silently use a different account.
• For rate limits or unavailable capacity, wait for the indicated delay. Review any new paid attempt before submitting it.
• For an explicit provider-credit error, check that provider’s billing account. Millwork credit covers the platform fee, not your provider’s model usage. A generic provider refusal does not establish that the balance is low.

Millwork cannot report a balance for every provider. Check the provider’s own account when you need that amount. If the cause remains unclear, send support the run ID, connection ID and a short redacted error. Keep the existing setup so they can investigate the same attempt.

​

AWS key, profile or access problems

If AWS rejects a key or access expires before a connection is created, return to the same saved setup’s browser step. If the connection already exists, renew access on that connection. For an API-key connection, generate a fresh short-term Bedrock key in the same source Region. For STS, supply a fresh complete session with its actual expiration. Keep the same method and source Region. API-key setup lists the account’s system profiles and requires the model already saved on that connection; STS keeps its exact inference-profile ARN. Then follow the saved application’s next step. For denied access or a profile mismatch, check the failed operation first. Reading profile information and invoking its model need different permissions. AWS setup recovery explains what to check with your AWS administrator. Inspect a failed run and its receipt before approving another paid attempt.

​

Replace or remove a key

Replace access on the same connection. Millwork tests the replacement before switching. A failed replacement keeps the previous settings; it does not restore access that has already expired or been revoked. If a credential may be exposed, revoke it promptly. To disconnect, use millwork provider list to find the connection ID, then follow Rotate or revoke a connection. Check its saved models before disconnecting. Millwork disables their use and schedules removal of the saved credential. A call already sent may finish. Other connections remain unchanged. If this was your selected connection, choose another model before your next task. An existing connection remains visible even when its provider is no longer offered for new setup. If the disconnect response is lost, read the connection: revoked_at records a completed disconnect. It does not prove that credential erasure has finished, or that the key was revoked at the provider.

​

Manage access at your provider

Use the account that owns the connection. For routine key replacement, confirm that the new access works before removing the old key. Short-term Bedrock keys expire in AWS and have no individual delete control. These links lead to provider instructions or account controls; they do not indicate availability in Millwork. Run millwork provider list for what your organization can connect now. For initial key-entry setup, prepare one active key from the intended provider project, workspace or account; provider scope IDs are not separate CLI inputs.