PowerBuilder REST API: 4 Integration Patterns That Actually Work

"Can PowerBuilder talk to REST APIs?" is the question. The answer is yes — even from PB 9. The harder question is which pattern to use, because there are four, and the wrong choice ages badly.

These four patterns cover essentially every PowerBuilder-to-REST situation we have shipped in production. Pick by your PB version, your auth requirements and how much logic the integration owns.

Pattern 1: Native HTTPClient (Appeon PowerBuilder)

Appeon PowerBuilder 2017 and onward shipped a proper HTTPClient with sane defaults. For most outbound REST calls from current PB, this is the right pattern. Code looks roughly like:

HTTPClient lh_client
String ls_response, ls_url
Long ll_status

ls_url = "https://api.example.com/v1/orders"
lh_client = create HTTPClient
lh_client.SetRequestHeader("Authorization", "Bearer " + is_token)
lh_client.SetRequestHeader("Content-Type", "application/json")

ll_status = lh_client.SendRequest("POST", ls_url, is_payload_json)
if ll_status = 1 then
   ls_response = lh_client.GetResponseBody()
   // parse JSON, handle response
end if

destroy lh_client

Wrap this in a service class (a non-visual object), add a retry loop and structured error handling, and you have a production-grade REST client in PowerScript. No external dependencies, no sidecar.

Use when: running Appeon PB 2017+ and the partner API uses Basic, Bearer or OAuth2 client-credentials. Most cases.

Pattern 2: WinHTTP wrapper (legacy PowerBuilder)

For PB 9 through 12.6 (Sybase era), no native HTTPClient exists. WinHTTP — a Windows COM component shipped since the early 2000s — is the cleanest path. It supports modern TLS, custom headers, all HTTP methods, and you can wrap it in a non-visual object that exposes the same API as Appeon's HTTPClient.

The wrapper is roughly 150 lines of PowerScript and stays stable for years. We have the same wrapper running across multiple client systems with no maintenance since 2021.

Use when: you are stuck on legacy PowerBuilder and an upgrade is not imminent. The wrapper is straightforward and survives later upgrades.

Pattern 3: Sidecar microservice

Sometimes the auth flow or the integration logic is genuinely complex — OAuth2 authorization-code with browser redirect, webhook signature verification with HMAC, retry logic with exponential backoff plus dead-letter queue, multi-step choreography. Implementing this in PowerScript is technically possible and practically painful.

The pattern: a small service (Node, .NET, Go, Python — pick what your IT runs) sits next to the PowerBuilder application, speaks REST to the world, exposes a simpler internal API to PowerBuilder. The PB app calls the sidecar over HTTP or through the database; the sidecar handles all the complexity.

Trade-off: now you have two things to deploy. Worth it only when the integration is genuinely complex. We see this most often for OAuth2-protected SaaS APIs and for any integration that needs background processing.

Use when: the auth flow needs a browser, the integration needs background workers, or you want to isolate the integration logic from the PB application lifecycle.

Pattern 4: Gateway in front (inbound webhooks)

PowerBuilder applications are thick clients. They have no HTTP server inside them. When a partner system needs to send you events — Stripe webhooks, HubSpot updates, internal microservice messages — there is nothing for them to call.

The pattern: a small HTTP endpoint sits in front (often the same as the sidecar in Pattern 3, or a serverless function in Azure / AWS), receives the webhook, validates the signature, and persists the event to a known location — typically a dedicated database table the PB application polls. The PB app reads new rows and acts on them.

This pattern is well-understood and not specific to PowerBuilder — it is the standard way thick-client applications integrate with event-driven SaaS. The only PB-specific work is the polling logic, which is straightforward.

Use when: a third-party system needs to push events to your PowerBuilder application.

Choosing the right pattern

A simple decision tree:

• Outbound REST, simple auth, Appeon PB → Pattern 1.
• Outbound REST, simple auth, legacy PB → Pattern 2.
• Outbound REST, complex auth or background workflows → Pattern 3.
• Inbound events → Pattern 4 (often combined with Pattern 1 or 3 for the call back).

The boring details that actually matter

Regardless of pattern, three things make the difference between a REST integration that ages well and one that doesn't:

1. Retry with backoff.Every network call fails sometimes. Code one retry loop, use it everywhere, log when retries fire. Don't let transient failures become incidents.
2. Structured error handling.HTTP status codes have meaning — distinguish 4xx (don't retry, fix the request) from 5xx (retry) from network errors (retry with backoff). PB code that treats all errors the same is a bug factory.
3. Timeouts.Set them explicitly on every call. The default in HTTPClient is "hope". Connection timeout (a few seconds) and read timeout (longer but bounded) are two different settings; configure both.

One more thing.Don't scatter REST clients throughout your codebase. Centralize them in two or three service classes, each owning the calls to a single external system. When the API changes, you fix one file. When a new system needs adding, the pattern is obvious.