How to create a Static Website Proof via the API

[pcardno]

Hi all,

We're trying to integrate Workfront Proof directly into our web build process, where we have automated tooling to create translations of sites and want to initiate Proofs on all the pages, which are public.

We want to initiate a Workfront Proof of a static page, which you can do in the UI via the www.shareyourlink.com box, which then generates the following type of Document, with a Proof on it:

https://experienceleague.adobe.com/docs/workfront/using/workfront-proof/wf-proof-tech-corner/proof-t...

I can create a Proof via the API, but only of an existing document, but I can't find anything in the documentation that explains how to create a Document that's actually a Static Website proof.

The documentation suggests, as far as I can tell, that we should sniff the network activity on the page to work out the Advanced Proofing Options, which isn't massively helpful, but doing so suggests that it's actually using a REST API on ProofHQ, rather than a SOAP API, which is again not massively helpful given that doesn't appear to be documented anywhere:

Unless that's a proxy onto the standard Workfront /upload REST API call:

So, I'm fairly stumped. Has anyone figured this out and got a pattern for it that they can share?

Thanks,

Paul.

[Madalyn_Destafney]

Hi there, have you checked out this article on how to create a static web proof of web content? Wondering if this is actually what you need - https://experienceleague.adobe.com/docs/workfront/using/review-and-approve-work/proofing/create-proo...

[pcardno]

Hi @Madalyn_Destafney - yep, that's how we know it can be done via the front-end. But we are trying to do it via the API.

We've managed to do it, so I'll add another post with details as to how.

[pcardno · Accepted solution]

Just in case anyone stumbles across this post and wants to do the same thing, we did manage to solve it by using the ProofHQ SOAP API, and then an undocumented endpoint in the Workfront API, which we found by reverse-engineering the UI (although it might be quite a common approach).

We firstly create the Proof in ProofHQ, via SOAP. Then we use /internal/documents/bulkImportProof from the Workfront endpoints to create a Document under a Project, which brings in the relevant proof.

Here's the code, from node.js, to do it

Create the Proof in SOAP HQ, where name parameter is the name I want the Proof to have, and sourceName is the URL of the webpage to be proofed:

Then create the document in Workfront using the bulkimportproof:

Note that in the above we've already got a session ID from Workfront via the OAuth2 approach, and the project has already been picked via a simple UI that we built in our application.

Also note that we had to do multiple retries on the CreateDocument, as Workfront fails silently fairly often. It returns an object with a property called "data" where the value is a Document Object ID, but maybe 10-20% of the time it didn't actually create it. So we immediately go back to check if it's actually there.

So not too bad, in the end. I've create a video showing it all in action here:

https://paulcardno.com/adobe/Generative%20Proofs%20via%20the%20API.mp4

Thanks,

Paul.