Published: September 6, 2026 · Last updated: September 6, 2026 · Author: Softix
A Power Automate custom connector is useful when a business system has a stable HTTP API but no connector that matches the workflow. It is not a magic wrapper that makes an unreliable API reliable. The integration still needs a contract, authentication, trigger semantics, retries, ownership, and a plan for duplicates.
Microsoft’s custom connector documentation supports OpenAPI-based definitions for Power Automate, Power Apps, and related services. Microsoft documents both webhook-based and polling triggers in its custom connector FAQ. Softix uses Contract–Trigger–Control: define the API contract, choose the right event trigger, and control retries, permissions, and lifecycle.
Start with the workflow, not the connector gallery
Write the business event and the desired action in plain language: “When a paid invoice is recorded, create a customer-success task,” or “When a new support case is assigned, notify the account owner.” Identify the system of record, the actor allowed to change it, the expected delay, and whether a duplicate action is harmful.
Then decide whether Power Automate is the right boundary. It can be a good fit for low-code orchestration, approvals, notifications, and cross-team workflows. A high-volume, latency-sensitive, or financially critical transaction may need a service you own, with a queue, database, and application-level idempotency. Do not put an irreversible payment or entitlement decision in a flow merely because the first demo works.
The Softix Contract–Trigger–Control model
1. Contract: describe a stable API
A custom connector starts with a service API, not a collection of screen clicks. Use an OpenAPI description to document servers, paths, operations, parameters, request bodies, responses, authentication, and error shapes. The definition should be readable by both the connector designer and the service owner.
Keep operation names business-oriented. CreateCustomerTask is more useful to a flow author than POST /v2/objects/17. Provide summaries, descriptions, examples, required fields, and safe response schemas. Mark identifiers and sensitive fields clearly. If the underlying API has a breaking version policy, document which version the connector targets.
Microsoft’s OpenAPI extension documentation lists Power Platform-specific extensions such as x-ms-summary, x-ms-visibility, x-ms-trigger, x-ms-notification-url, and x-ms-notification-content. Use extensions to improve the connector experience, but keep the underlying API contract understandable without them.
Define errors that a flow can handle. A 400 should tell the author which input is invalid; a 401 or 403 should not be retried blindly; a 409 can signal a duplicate or state conflict; a 429 should expose retry guidance when possible; a 5xx may be transient but is not proof that repeating a write is safe.
2. Trigger: choose webhook or polling deliberately
A webhook trigger lets the source system notify the flow when an event occurs. Microsoft’s webhook tutorial explains that a custom connector definition describes the callback URL and notification payload. The source API typically needs a registration operation and a delete operation so the subscription can be created and removed as the flow changes.
Use a webhook when the source can deliver trustworthy events, the event payload has enough identity to fetch the current record, and the source can revoke or renew subscriptions. Design for retries and duplicate delivery. The receiver should acknowledge quickly, queue work when needed, and process the same event safely more than once.
Polling asks the connector to call the source at intervals and check for new data. It can work when the source has no webhook facility or when events are too unreliable to trust. It introduces delay, repeated reads, rate-limit pressure, and cursor design. Poll by a durable watermark such as updated timestamp plus stable ID, not by “the last page I happened to see.” Handle clock skew and records updated more than once.
The right trigger is sometimes a hybrid: use a webhook to wake the flow, then fetch the authoritative record through an action. Do not treat a webhook payload as complete if the source can change the record after the event.
3. Control: make automation safe to operate
Idempotency is the first control. If the same event arrives twice, the action should produce one business result. Pass an event ID or source record version to a deduplication store when available. If the target API supports an idempotency key, use it. If neither side supports one, design a lookup-and-create operation carefully and document its race conditions.
Authentication must match the service. Microsoft documents several custom connector security options; select the least-privileged method the API supports, and make ownership clear when a connection represents a person versus a shared business identity. A flow that uses a departing employee’s personal connection is an offboarding failure waiting to happen.
Limit what the connector exposes. Hide internal operations, test endpoints, destructive actions, and fields that flow authors do not need. Use environments, connection references, and solution packaging according to your Power Platform governance model. Do not copy production secrets into an OpenAPI file or a flow description.
Treat retries as business behavior. A retry of “send notification” may be harmless; a retry of “issue refund” may not be. Set timeouts and retry policies near the operation, inspect the source API’s rate limits, and create a dead-letter or manual-review path for failures that cannot be resolved automatically.
Webhook versus polling decision table
| Question | Prefer webhook | Prefer polling |
|---|---|---|
| Source supports reliable subscriptions | Yes | Not required |
| Near-real-time response matters | Usually | Only with acceptable interval and limits |
| Source has no callback API | No | Yes |
| Event can be duplicated | Design idempotency | Design cursor and idempotency |
| Source record changes after event | Fetch current record | Fetch current record |
| Operations team needs simple recovery | Subscription lifecycle must be owned | Cursor and missed-window recovery must be owned |
Do not choose webhooks just because they sound real-time. An unreliable webhook without replay or reconciliation can be worse than a slower poll with a clear watermark. Do not choose polling because it is familiar if the source rate limit makes the workflow impossible at scale.
A safe connector delivery process
Discover: interview the process owner, list systems of record, identify sensitive actions, and write the event-to-action map.
Contract: obtain the API documentation, test authentication, define OpenAPI schemas, and agree on error and version behavior with the service owner.
Trigger: prototype webhook registration or polling with realistic updates, duplicates, out-of-order events, missed events, and deleted records.
Control: add idempotency, least privilege, retry limits, alerting, manual review, and audit information. Test what happens when the connector or source is unavailable.
Release: package the connector with clear descriptions, owner, environment rules, support route, and a rollback or disable procedure.
When to build a direct integration instead
A custom connector is a presentation and orchestration boundary. A direct integration may be better when the workflow is core product behavior, needs high throughput, must guarantee ordering, requires a durable queue, or contains complex reconciliation. You can still expose a narrow action to Power Automate after the core service owns the difficult guarantees.
Cost is more than connector creation. Include API maintenance, connector changes when the source version changes, flow review, connection ownership, premium licensing or request limits where applicable, incident response, and support. Microsoft’s limits documentation is a starting point, not a substitute for checking the plan and environment you will actually use.
Common mistakes
- Building from a Postman demo without an owned OpenAPI contract.
- Treating webhook delivery as exactly once.
- Polling with a timestamp only and losing records with equal timestamps.
- Retrying writes without idempotency.
- Exposing admin or destructive operations to every flow author.
- Using a personal connection for a business process.
- Putting secrets, private URLs, or customer data in connector descriptions.
- Having no owner for subscriptions, flow failures, or source API upgrades.
FAQ
Are Power Automate custom connectors only for REST APIs?
Microsoft’s FAQ says Power Automate and Power Apps custom connectors require stable HTTP REST APIs, while Logic Apps may also support SOAP in some scenarios. Confirm the current product documentation and plan before choosing an integration path.
Is a webhook always better than polling?
No. A webhook can reduce delay and unnecessary reads, but it needs subscription lifecycle management, replay or reconciliation, and idempotent processing. Polling can be the more predictable choice when the source lacks reliable events.
Should an SMB put core billing logic in Power Automate?
Usually keep the authoritative billing and entitlement logic in a service you control. Use Power Automate for notifications, approvals, and bounded orchestration unless you have deliberately designed the flow’s reliability, audit, and recovery controls.
A practical next step
If an important business workflow is trapped between a SaaS API and a connector demo, Softix can define the OpenAPI boundary, choose webhook or polling semantics, and build the safeguards around retries and ownership. Explore business-ready custom software or contact Softix for an integration assessment.
Share
