A Power Platform custom connector can expose a controlled OpenAI API operation to Power Apps and Power Automate. It is not a connection to the ChatGPT website, and an API project is billed and governed separately from a ChatGPT account.
The old version of this article used a retired model and treated an API key as a minor setup detail. In a real tenant, authentication, licensing, data policies and error handling are part of the build.
Verified on 24 August 2026 against Microsoft Learn and OpenAI's current platform documentation. Confirm the endpoint, model and commercial terms in your own accounts before rollout.
Choose the simplest supported route
Before creating a connector, check whether an approved connector, Azure OpenAI route or existing organisation service already meets the need. A custom connector is justified when you need a deliberately small contract of your own, such as CreateDraftSummary, with inputs and outputs that makers can understand.
Do not expose the whole OpenAI API merely because you can.
Prerequisites
You need:
- a Power Platform environment where you may create custom connectors
- a Power Apps or Power Automate licence that covers custom connector use
- an OpenAI API project with billing and a restricted project key
- an agreed data policy classification for the connector's host
- non-sensitive test data and a named owner
Microsoft documents custom connectors as premium capability. Licensing varies by product and agreement, so check the current licensing guide rather than assuming Microsoft 365 alone covers production use.
Build a small connector
1. Define the API contract
Start from OpenAI's current API reference. For new work, prefer the operation OpenAI currently recommends for your use case rather than copying the former gpt-3.5-turbo Chat Completions example.
Create a narrow request schema. Typical fields are the user's task, permitted context and response format. Define successful and error responses so the app does not treat every HTTP result as usable text.
Microsoft's OpenAPI import route currently expects an OpenAPI 2.0 definition under its documented size limit. You can also define the operation in the custom connector wizard.
2. Configure authentication
An OpenAI project key is a secret. Store it in the connector connection, never in a canvas-app formula, SharePoint list, environment variable visible to users or exported screenshot.
For stronger separation, put an API Management, Azure Function or other controlled service between Power Platform and the provider. That service can keep the provider key server-side, enforce quotas, validate requests and record safe audit metadata.
3. Test in the connector
Create a connection and run the connector's test operation with synthetic content. Microsoft notes that a newly created API-key connector can take a few minutes before it is ready to test.
Check a successful response plus authentication failure, rate limiting, timeout, invalid JSON, empty output and a provider safety refusal. Your action should return a useful error object, not an unhandled blob.
4. Use it from an app or flow
Call the narrow action from Power Apps or Power Automate. Show a waiting state, block duplicate submissions and render the output as a draft.
Never let model text directly set permissions, approve money, send external messages or update regulated records without deterministic validation and the appropriate human approval.
Governance is not optional
Power Platform data policies can classify custom connector endpoints and control which connector groups may exchange data. They reduce accidental data movement but do not prove that the provider, prompt, retention or output is safe.
Share the connector only with intended makers or users. Audit its owner, connections and dependent apps. Rotate the provider key without editing every app, and document what happens when the key expires or the provider changes a model.
OpenAI states that API data is not used for training by default. Its data-control documentation also describes default abuse-monitoring retention and endpoint-specific application state. Review the exact endpoint and any approved retention controls before sending business data.
Proof boundary
A successful connector test proves that the defined operation returned a response with that connection. It does not prove output accuracy, licence coverage, production capacity, privacy compliance or suitability for confidential data.
For practical connector designs that include licensing, errors and ownership, join the Power Apps Builders Space.