Calling an external REST API (PATCH + Bearer/OAuth2) from Communications Server 16.6.x — native conn

Question

Hi all,

We're running Communications Builder/Communications Server 16.6.2, and have a requirement to call an external REST API immediately after a document is successfully generated (per-document, not once per batch), to notify a downstream system of the new document's location.

The target API requires:

* HTTP method: PATCH
* Authentication: Bearer token (OAuth2 client credentials flow — token endpoint, client_id/client_secret, access_token with expiry)
* A custom JSON request body (not the rendered document itself)

We evaluated the native HTTP(S) Submit output connector, but based on its documented settings:

* Supported methods are POST and PUT — no PATCH.
* Supported authentication is Basic/Digest (RFC 2617) — no Bearer/OAuth2 option.
* The connector's model appears to be built around submitting the generated output itself as the request body, rather than an arbitrary custom payload.

A few specific questions, if anyone has direct experience:

* Does the HTTP(S) Submit connector's "Custom header" field support dynamic values (e.g. populated from a script variable at runtime), or is it a fixed, static value set at design time? If dynamic, is there a documented pattern for refreshing a Bearer token and injecting it per-request?
* Can the HTTP(S) Submit connector send an arbitrary JSON body unrelated to the rendered document output, or is the request body always tied to the generated output?
* Is there any native connector or profile type (e.g. web service profiles, OAuth profiles) that supports Bearer/OAuth2 authentication for a generic outbound HTTP call — not tied to a specific named partner product (we've found OAuth profiles scoped to SMTP, and web service profiles scoped to specific integrations like Output Manager/EasyLink)?
* Has anyone found a native way to conditionally skip an output connector firing based on a per-document business condition (e.g. only call the API if a validation check passed), without resorting to script-level logic?

We ended up building this via JavaInvokeStaticMethod calling a custom Java class, which works well, but wanted to check whether we've missed a native option before committing to that as the long-term approach.

Thanks in advance for any insight.

vivek sharma · Answer

Thanks for the ideas, Vyv - appreciate you thinking this through with us.

On batching - here's roughly our flow, which is why it's a bit more involved than it first looks:

* One XML input file arrives, containing ~100 accounts, each needing its own PDF.
* For each account, once its PDF is successfully generated, we call the API with that account's ID.
* If the API call succeeds, we mark it processed. If it fails, we log that ID separately (e.g. to a CSV) so it can be reprocessed/looked at later.
* There's also a case where the PDF is still generated, but we deliberately do NOT call the API at all - this happens when an internal calculation check (comparing the invoice amount against our own records) doesn't match. In that case the PDF exists, but the invoice itself may be wrong, so it needs manual review before anyone downstream is notified.

So each of the 100 accounts in one XML can end up in three different states (API success, API failure, or deliberately skipped due to a data validation issue), and we need to track each one individually, not as a single pass/fail for the whole batch. That's the main reason a simple "batch of 100 in one call" doesn't fit cleanly, unless the target API can return a precise per-item result for each ID in a batch rather than one aggregate response. Worth checking on the API side.

On rate limiting - honestly not sure yet, fair thing to check on our end too. Will find out.

On the custom header question - fair push back, we haven't actually tried it directly yet, only gone by the documentation. That's exactly the gap we want to close with a hands-on test rather than keep guessing at. Will report back once we've tried it.

Thanks again for engaging with this - genuinely helpful to think it through out loud.

Vyv · Answer

Is it possible to batch the PATCH lines?

E.g. doc ID 1 - 6040 = OK in one call and then doc ID 6041,6042 = NOK in another and then doc ID 6043 - 9999 = OK

Is there a rate limit on your endpoint?

You could script the curl call as an array at the end of the job in one process (or batch that too).

With regard to your question 1 - I believe that any variable can be used - have you not tried it?

vivek sharma · Answer

Thanks for the reply @Vyv.

That's actually where we started - execute()+curl. In our case, we're generating on the order of tens of thousands of PDFs per run, with an API call per document, and that setup caused a significant performance regression (roughly 3x longer total processing time).

Given that scale, is execute()+curl still the best available option, or has anyone found a way to make outbound calls from within Communications Server without spawning a separate process per call? Trying to understand if there's a lower-overhead path before we commit to this approach long-term.

Also still curious if anyone has direct experience with questions 1-4 above, particularly whether the HTTP(S) Submit connector's custom header field can take a dynamic/scripted value - that's the one thing we haven't been able to confirm either way from documentation alone.