A key is not the whole integration
The application must know which supported service it calls, what request format it uses and how to validate the result. It also needs the business trigger and the permissions for any subsequent action. Pasting an API key into an admin field only supplies access. Forge’s AI Native Processes includes designing and testing the workflow around that connection.
Keep production credentials server-side
The module should use protected backend configuration and avoid placing raw keys in browser code, exported examples or ordinary logs. Mask saved values in the administration and provide explicit replacement and revocation actions. Test credentials used during development are distinct from the production key. Do not copy the engineering agents’ access into the generated application.
Make limits and failures understandable
A provider can reject a request, exhaust a budget or return an unusable response. Define a bounded retry policy and a manual path where the process requires one. A connection error should not make the application pretend the AI task succeeded. Show the affected operation without exposing the secret or confidential prompt. Customer-selected budgets remain distinct from an unlimited service promise.
Keep operation independent from development billing
After deployment, the customer pays the chosen AI provider directly. The delivered module does not route its model traffic through a Yepsy resale gateway. Ending Forge development or optional dependency monitoring should not itself disable that module. Its hosting and external provider connection must still work, and the application remains responsible for its workflow and access rules.
Keep runtime credentials in the application’s own boundary
An AI module delivered by Forge needs an authorized connection to a provider. That connection belongs to the client and is configured in the application’s administration. It is different from the credentials used by the Architect or Developer while building the software. The client pays its runtime provider directly.
Store the secret server-side, show only masked metadata and support replacement or revocation. Do not ship a key in a public JavaScript bundle, screenshot, source archive or sample configuration. The form should verify configuration separately from an explicitly authorized paid test.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Storage | Server-side secret reference. | No credential in browser payloads or logs. |
| Limits | Bounded requests, retries and spend. | Application controls and provider settings. |
| Failure | An invalid key pauses the AI step clearly. | No silent funded fallback. |
Where this goes wrong
The client should understand what information leaves the application and which service receives it. A key is permission to use an API, not a reason to send all business records. Minimize payloads and keep uploaded content separate from the instructions governing tools.
The customer owns the connection and the running application, not just the exported code.
Turn it into a working checklist
- Separate test and production keys.
- Store secrets only in protected backend settings.
- Bound retries and spending.
- Keep runtime independent of Forge development billing.
A concrete next step
Provide an operator guide covering provider selection, key rotation, test mode, limits and manual continuation when AI is unavailable. The deployed module should not depend on an active Forge development subscription.
Watch a related case
The video could not be loaded. Try again later.